[ofw] [PATCH] complib/user: fix timer race conditions
Fab Tillier
ftillier at microsoft.com
Mon Jun 28 10:50:00 PDT 2010
Tzachi Dar wrote on Mon, 28 Jun 2010 at 10:46:37
> The simple solution is to create a thread and to use timeout options of
> waitforsingleoject. All other solutions are much more complicated than
> what one would think.
Why bother, just have opensm create a thread and do a sleep itself. Having a timer abstraction that just uses a thread for each timer, while functional, isn't really a good abstraction.
-Fab
>
> Thanks
> Tzachi
>
>> -----Original Message-----
>> From: Hefty, Sean [mailto:sean.hefty at intel.com]
>> Sent: Monday, June 28, 2010 8:26 PM
>> To: Hefty, Sean; Tzachi Dar; Smith, Stan; Fab Tillier;
>> ofw at lists.openfabrics.org
>> Cc: Uri Habusha; Yevgeny Kliteynik
>> Subject: RE: [PATCH] complib/user: fix timer race conditions
>>
>>> I don't follow their logic. If the OS can't automatically clean up
> a
>> one-
>>> shot timer, then there's no way our abstraction can... The timer APIs
>>> seem pretty weak, and the documentation vague at best.
>>
>> I submitted a comment about the documentation. I also threw together a
>> quick test to verify that without the call to DeleteTimerQueueTimer
>> that there is a memory leak.
>>
>>> struct timer_osd
>>> {
>>> cl_timer_t *p_timer;
>>> HANDLE timer;
>>> };
>>>
>>> in cl_timer_trim() and pass that to the timer callback. The
> callback
>> calls
>>> DeleteTimerQueueTimer if it has not already been called for the
> timer
>> in
>>> question.
>>
>> I'll update the patch to do something similar to this, to ensure that
>> we have matching Create-Delete calls and re-submit, unless someone sees
>> a simple solution.
More information about the ofw
mailing list