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:[email protected]] >> Sent: Monday, June 28, 2010 8:26 PM >> To: Hefty, Sean; Tzachi Dar; Smith, Stan; Fab Tillier; >> [email protected] >> 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. _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
