Re: LDT initialization after fork() for LinuxThreads?

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

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.