This is the mail archive of the
mailing list for the glibc project.
Re: TSD destructors not being called for initialthread
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- To: Boris Kolpackov <boris at kolpackov dot net>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 31 Mar 2004 11:38:07 -0800 (PST)
- Subject: Re: TSD destructors not being called for initialthread
On Wed, 31 Mar 2004, Boris Kolpackov wrote:
> Date: Wed, 31 Mar 2004 13:32:13 -0600
> From: Boris Kolpackov <firstname.lastname@example.org>
> To: Kaz Kylheku <email@example.com>
> Cc: firstname.lastname@example.org
> Subject: [libc-alpha] Re: TSD destructors not being called for initial
> Hi Kaz,
> > > Also it never says that this does not apply to the initial thread.
> > That is true. However, there are no guarantees about how soon the
> > cleanup happens. If the cleanup is delayed until the process
> > terminates, then it's okay for it not to happen.
> Says who? What if I allocate some non-local (process-wise) resources
> and need to release them?
What if your process crashes? What if something calls exit() and blows
away all threads, or, equivalently, the main thread returns from the
The TSD cleanup mechanism does not ensure that the functions are called
no matter how the process terminates, so you can't rely on it for
fail-safe cleanup of persistent resources.
> > The spec doesn't say that the first destructor must be called within X
> > milliseconds of the pthread_exit().
> Well, I would expect that destructors will be called right after
> the stack has been unwound. But of course there is always a way
> to astonish people and be compliant ;-)
If you can pthread_join() that thread, and its destructors were not
called, or not yet called, that's a bug. Those events can't be ordered
A valid program could depend on the ordering; a destructor could
compute something or produce some side effect that is relied upon after
synchronizing on the termination with pthread_join.