This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: LDT initialization after fork() for LinuxThreads?
- To: Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>
- Subject: Re: LDT initialization after fork() for LinuxThreads?
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Wed, 27 Jun 2001 12:44:04 -0700 (PDT)
- cc: <libc-alpha at sources dot redhat dot com>
On Wed, 27 Jun 2001, Wolfram Gloger wrote:
> Date: Wed, 27 Jun 2001 16:46:46 +0200 (MDT)
> From: Wolfram Gloger <Wolfram.Gloger@dent.med.uni-muenchen.de>
> To: libc-alpha@sources.redhat.com
> Subject: LDT initialization after fork() for LinuxThreads?
>
> Hi,
>
> Maybe I'm missing something obvious, or I just don't understand the
> LDT stuff sufficiently.
>
> But, my tests indicate that modified LDT entries aren't inherited
> across fork(). So, aren't we missing something like the untested
> patch below, since __pthread_reset_main_thread() doesn't do any
> INIT_THREAD_SELF?
It looks that way. Actually what is missing is a good set of test cases
for fork() under threads. All the fork-related bugs I fixed in the past
were found by code inspection.
We need tests which do these things:
- try to make stdio streams fail in a forked child process: crash or
deadlock in fopen or fclose, since these manipulate the global list
of streams; crash, deadlock or corruption of stream data in the I/O
functions.
- performs pthread_once() in a parent concurrently with
fork(), and then pthread_once() in children, trying to find an
instance of an incomplete once-initialization in the parent not being
re-run in the child.
- tries to calls pthread_atfork() at the same time as fork() in
parent, then uses pthread_atfork() in the child.
- some general sanity test which provides a measure of confidence that
threads are working in the forked process.
POSIX gives the implementor a way out of providing sane behavior in
this area of the interface by stating that only async safe funtions may
be used by the child of a multithreaded process. In practice, a lot
more can be provided and documented by the implementor.