What happens to other threads when one thread forks()?

Question

In C++ using pthreads, what happens to your other threads if one of your threads calls fork?

It appears that the threads do not follow. In my case, I am trying to create a daemon and I use fork() with the parent exiting to deamonize it. However, in a new path through the code, I create some threads before the fork and some after. Is there an easy way to change ownership of the threads over to the new forked process rather than moving all my thread creation after the fork?

Solution 1

Nothing. Only the thread calling fork() gets duplicate. The child process has to start any new threads. The parents threads are left alone.

Solution 2

In POSIX when a multithreaded process forks, the child process looks exactly like a copy of the parent, but in which all the threads stopped dead in their tracks and disappeared.

This is very bad if the threads are holding locks.

For this reason, there is a crude mechanism called pthread_atfork in which you can register handlers for this situation.

Any properly written program module (and especially reusable middleware) which uses mutexes must call pthread_atfork to register some handlers, so that it does not misbehave if the process happens to call fork.

Besides mutex locks, threads could have other resources, such as thread-specific data squirreled away with pthread_setspecific which is only accessible to the thread (and the thread is responsible for cleaning it up via a destructor).

In the child process, no such destructor runs. The address space is copied, but the thread and its thread specific value is not there, so the memory is leaked in the child. This can and should be handled with pthread_atfork handlers also.

Solution 3

Quoting from http://thorstenball.com/blog/2014/10/13/why-threads-cant-fork/

If we call fork(2) in a multi-threaded environment the thread doing the call is now the main-thread in the new process and all the other threads, which ran in the parent process, are dead. And everything they did was left exactly as it was just before the call to fork(2).

So we should think twice before using them

Solution 4

It's usually very bad to fork a thread. The forked process is supposed to be a complete copy of the parent, except with threads it isn't. There is a function pthread_atfork() which helps sometimes. If you must fork a thread, it is best if you call exec() immediately after the fork().

I suggest you read the caveats from the POSIX developers in the documentation of fork() and pthread_atfork() (See http://pubs.opengroup.org/onlinepubs/007904975/functions/fork.html and http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_atfork.html ).

From the fork() documentation:

The fork() function is thus used only to run new programs, and the effects of calling functions that require certain resources between the call to fork() and the call to an exec function are undefined.

View more solutions

Comments

[Dacav]

As you might have figured out by now, this is a really bad idea. If you have this kind of concern in a real application, I'd suggest to find out the reason why you should do that, figure out how the right way to do it and do a proper refactoring :D

[WilliamKF]

What happens to the threads when the parent of the fork exit()s?

[Andrew T Finnell]

@WilliamKF stackoverflow.com/questions/395877/…

[Soner from The Ottoman Empire]

I genuinely wonder why anybody has yet to do upvote the answer until now 🤔🤔🤔🤔

[Ilya Loskutov]

the effects of calling functions that require certain resources between the call to fork() and the call to an exec function are undefined. Could you explain what does this line mean? It's quite defined that such "intermediate" functions would have per-process resources and current-thread ones, but not the resources related to other threads. So what is "undefined" here?

[David Hammen]

@Mergasov You need to adjust your thinking. When an organization such as the committees that define the POSIX, C, and C++ standards say that behavior is undefined, what they mean is that any behavior by an implementation of the standard will be considered compliant with the standard. What you think should be "quite defined" is not the case. Two canonical examples of acceptable behavior by an implementation in the case of undefined behavior are to erase the offending user's hard drive and/or to make demons fly out of the offending user's nose. Google the term "nasal demons".