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?

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 — Dacav, Jun 17 '17 at 09:31

score 29 · Accepted Answer · answered Apr 09 '12 at 22:45

29

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

answered Apr 09 '12 at 22:45

Andrew T Finnell

13,417
3
33
49

2

What happens to the threads when the parent of the fork exit()s? – WilliamKF Apr 09 '12 at 22:53
@WilliamKF http://stackoverflow.com/questions/395877/are-child-processes-created-with-fork-automatically-killed-when-the-parent-is – Andrew T Finnell Apr 10 '12 at 00:29

score 20 · Answer 2 · answered Apr 09 '12 at 23:02

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.

score 7 · Answer 3 · answered Oct 14 '14 at 08:01

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

score 4 · Answer 4 · answered Apr 09 '12 at 23:02

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.

answered Apr 09 '12 at 23:02

David Hammen

32,454
9
60
108

1

`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? – Ilya Loskutov Oct 01 '21 at 11:18
1

@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". – David Hammen Oct 01 '21 at 12:58

score -2 · Answer 5 · answered Apr 09 '12 at 22:47

-2

Nothing, unless one happens to be preempted by the thread running the new process.

answered Apr 09 '12 at 22:47

Martin James

24,453
3
36
60

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

5 Answers5

Linked