Re: Cleaning up after timer_delete

["Rémi Denis-Courmont" <remi at remlab dot net>]

Le samedi 25 juillet 2009 22:39:02 Carlos O'Donell, vous avez écrit :
> Can you guarantee your application runs only using NPTL pthreads?

Unfortunately, I think that is irrelevant altogether. For SIGEV_THREAD, glibc 
needs the helper thread regardless of the kernel support for POSIX timers. As 
of today, the kernel is not capable of delivering timer events via threads - 
from include/asm-generic/siginfo.h (Linux 2.6.31-rc4):
/*
 * sigevent definitions
 *
 * It seems likely that SIGEV_THREAD will have to be handled from
 * userspace, libpthread transmuting it to SIGEV_SIGNAL, which the
 * thread manager then catches and does the appropriate nonsense.
 * However, everything is written out here so as to not get lost.
 */
#define SIGEV_SIGNAL    0       /* notify via signal */
#define SIGEV_NONE      1       /* other notification: meaningless */
#define SIGEV_THREAD    2       /* deliver via thread creation */


> The case you describe is the later, userspace uses a normal timer to
> emulate SIGEV_THREAD. In this case timer_delete unlinks the timer from
> the timer list, the unlink operation is atomic and timer_delete holds
> the __timer_mutex. The previous conditions IMO would guarantee that
> calling timer_delete makes sure that nothing else will run after that
> call.

No! That unlinking guarantees that no new threads will be created after 
timer_delete(). It does NOT guarantee that *existing* threads are *terminated* 
or not. If I knew there was only one thread, I could cope with it. If I knew 
there were none - trivial. But I have no idea how many threads are still there 
because they were started *before* timer_delete() yet they did not exit by the 
time timer_delete() acquired the timer list lock, unlinked the timer, and 
released the list lock.

Note that the helper thread releases the list lock once after calling 
pthread_create() *not* pthread_join().

> The complicated case is where timer_create is implemented by the
> kernel, and userspace has no ability to intercept a signal or use
> locks to synchronize. You will have to see what the kernel does in the
> case of timer_delete, does it dequeue all pending thread creations?

I want to know that there threads are _terminated_ so that I can release data 
that those threads use. I cannot release data if threads are still using it, 
regardless of when they were created.

And I cannot release data from the timer callback either because I do not know 
which thread is "the last one". There could be *more* than one thread still 
running after timer_delete() afterall.

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