This is the mail archive of the
mailing list for the glibc project.
Re: TSD destructors not being called for initial thread
- 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: Tue, 30 Mar 2004 16:36:40 -0800 (PST)
- Subject: Re: TSD destructors not being called for initial thread
On Tue, 30 Mar 2004, Boris Kolpackov wrote:
> Date: Tue, 30 Mar 2004 16:32:02 -0600
> From: Boris Kolpackov <firstname.lastname@example.org>
> To: email@example.com
> Subject: [libc-alpha] TSD destructors not being called for initial thread
> Good day,
> Just noticed that deallocate_tsd is not being called for initial
> thread (i.e. the one that runs main). Should there be something
> similar to __pthread_initialize_minimal for deallocate_tsd in
TSD cleanup for the main thread only makes sense if it calls
pthread_exit or otherwise terminates in a way that does not take down
the whole process.
It therefore doesn't make sense to do it as a part of the global
How it works in LinuxThreads is that if the main thread calls
pthread_exit() then the associated light-weight process does not
actually terminate, but is parked in the library waiting for the other
threads to exit. When they all do, then the process manager shuts
itself down and signals the main thread to proceed. The thread then
performs the global process shutdown (calling atexit handlers, flushing
standard IO streams ...).
If you want TSD cleanup to happen, a good place would be to insert the
logic just before the thread goes to sleep to wait for the others to
terminate. This way it is done soon after the pthread_exit() call.
Programmers who expects a main thread's pthread_exit() to perform TSD
destructor calls probably expect those calls to happen soon after the
thread exits, rather than after a possibly long delay to process
For any other cases, like when the main thread returns from main() or
the process is terminated by exit() or some other way, there is no
point in doing TSD cleanup, because threads are blown away. If you
aren't going to do it for all the threads, it doesn't make sense to do
it for one. This is another reason to do it before the termination wait
rather than after, if you are going to do it at all.
TSD cleanup is designed to prevent resource leaks in programs that
create and terminate lots of threads; it's not for cleaning up process
resources. If TSD contains a reference to some resource that has to be
cleaned up no matter how the process terminates (and is not cleaned up
automatically by the system), then TSD destructors are not the
appropriate mechanism to arrange that cleanup.