This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Cleaning up after timer_delete


	Hello,

I'm trying to use POSIX timers inside a (threaded) library. Using signal 
notification is not really an option since I don't know what signal numbers 
the main program needs, so I'm using thread notification(SIGEV_THREAD).

Now, I'm wondering how to reliably clean up. If I'm not mistaken, after 
timer_delete() returns, there is a warranty that no new notifications will 
happens, but there could be any number of notification still being processed 
in their own thread. My reading of POSIX as well as the glibc source code 
seems to confirm this.

So, I'm starting to believe that there is basically no way to releases 
allocated resources that a timer notification function uses. If I release 
(e.g. free()) the datum after timer_delete() returns, a pending notification 
could end up doing use-after-free. I'd release the datum at the end of the 
notification function - but I could not figure a way to determine that "this" 
is the last remaining notification since the timer was otherwise deleted.

So in other words, I need to re-invent the wheel and create my own timer 
subsystem?? :-(

Best regards,

-- 
RÃmi Denis-Courmont
http://www.remlab.net/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]