This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Cleaning up after timer_delete
- From: "RÃmi Denis-Courmont" <remi at remlab dot net>
- To: libc-help at sourceware dot org
- Date: Thu, 23 Jul 2009 20:52:20 +0300
- Subject: 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/