This is the mail archive of the
mailing list for the glibc project.
Re: [libc-alpha] mt-application hanging in exit()
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- To: Bertold Kolics <Bertold dot Kolics at Sun dot COM>
- Cc: <libc-alpha at sources dot redhat dot com>
- Date: Fri, 18 Jan 2002 16:02:46 -0800 (PST)
- Subject: Re: [libc-alpha] mt-application hanging in exit()
On Fri, 18 Jan 2002, Bertold Kolics wrote:
[ reformated to 79 cols ]
> I suspect that this race condition only happens if the *only* thing
> the thread manager has to do is to send a restart signal to the issuing
> thread when servicing a REQ_PROCESS_EXIT request. Otherwise, the thread
> manager will send cancel signals to the other threads and thus will give
> a chance to the suspend() to finish in the main thread before sending
> a restart signal to it.
suspend() and restart() are fundamental to all synchronization in
LinuxThreads. If they are broken, then the problem is much more serious
than hanging in exit() symptom you are seeing, and requires a real fix.
> I've modified the glibc in the following manner:
> - I didn't see any good reason why we need signalling in case the
> process is about to exit: the user thread will wait for the thread manager
> to exit (using waitpid()), so I don't see why an extra signal is needed.
I don't have the code before me, but one thing to remember is that a
thread other than the main thread is permitted to call exit(). Threads
other than the main one cannot waitpid() for the thread manager, because
it is their parent, not their child.