Linux/POSIX: Why doesn't fork() fork *all* threads

Question

It is well-known that the default way to create a new process under POSIX is to use fork() (under Linux this internally maps to clone(...))

What I want to know is the following: It is well-known that when one calls fork() "The child process is created with a single thread--the one that called fork()" (cf. https://linux.die.net/man/2/fork). This can of course cause problems if for example some other thread currently holds a lock. To me not also forking all the threads that exist in the process intuitively feels like a "leaky abstraction".

So I would like to know: What is the reason why only the thread calling fork() will exist in the child process instead of all threads of the process? Is there a good technical reason for this?

I know that on Multithreaded fork there is a related question, but the answers given there don't answer mine.

Answer 1

Of these two possibilities:

• only the thread calling fork() continues running in the child process

  Downside: if another thread was holding on to an internal resource such as a lock, it will not be released.

• after fork(), all threads are duplicated into the child process

  Downside: threads that were interacting with external resources continue running in parallel. If a thread was appending data to a file: now it happens twice.

Both are bad, but the first one choice only deadlocks the new child process, while the second choice results in corruption outside of the process. This could be described as "bad".

POSIX did standardize pthread_atfork to try to allow automatic cleanup in the first case, but it cannot possibly work.

tl;dr Don't use both threads and forks. Use posix_spawn if you have to.