This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: problem with pthread and waitpid()
- To: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Subject: Re: problem with pthread and waitpid()
- From: Britton <fsblk at aurora dot uaf dot edu>
- Date: Wed, 20 Sep 2000 10:34:36 -0800 (AKDT)
- cc: libc-alpha at sources dot redhat dot com
> > I have noticed a problem with the LinuxThreads implementation. When a
> > process forks and execs a program that spawns threads, then waitpids on
> > that child, the wait ends when the initial thread of the exec'd program
> > finishes, but before the spawned threads are necesarilly dead.
>
> Which version of LinuxThreads and how are the threads terminating?
I guess I skipped the important part of the story, which is that the
program getting waitpid()ed on is getting SIGTERM ed first. So far as I
can tell everything works correctly when there is no such fatal signal
delivered to the initial thread. But this (from libc/linuxthreads/README
is not strictly true
2- A fatal asynchronous signal terminates all threads in the process.
(OK. The thread manager notices when a thread dies on a signal
and kills all other threads with the same signal.)
There is a timing glitch during which the initial thread may be dead but
resource hungry children still alive. I guess this falls into the
category of things that can't be fixed until CLONE_PID works. Anyone know
if it does in 2.4?
> I addressed a couple of bugs related to LinuxThreads shutdown since 2.1.3. The
> two that I recall off the top of my head are:
>
> - a potential unnecessary two second delay in shutdown due to the 2000
> millisecond poll() timeout in the thread manager's loop.
Thank you thank you thank you. I have already been bitten by this.
Britton