threads/76690: fork hang in child for (-lc_r & -lthr)

[Sven Berkvens-Matthijsse]

> WRT to malloc() and free() within libc_r, it is always single
> threaded from the library's perspective because no other threads can
> be active at the time of the fork (libc_r is all userspace threads).

Correct. It also takes care to disable the signal handler that may
cause a thread switch in the "thread kernel".

> Probably all that needs to be done is take the malloc lock before
> forking and release it afterwards (like libpthread).

That's possible (and indeed what I do). I decided to lock the other
locks as well because programs (buggy or not) may call those library
functions after the fork (in the child) as well. We can remove those
locks if you wish, none of the functions involved are async-signal-safe,
and programs shouldn't be using them after a fork() in a threaded
program.

> It may even be enough just to set __isthreaded to 0 in the child
> after the fork() before calling any malloc()'s and free()'s so they
> don't try to use the lock.

But then the free() in the child process may be using an unstable
state of the malloc system (because if you don't acquire the lock
before the fork(), malloc() may be busy in the middle of the fork()).

> If __isthreaded is 0 in the child, I don't think any part of libc
> will attempt to use locking.

That's correct.

> If the child tries to create any threads, then bad things may
> happen, but that's the application's fault.

True.

> -- 
> DE

-- 
Sven