0

I'm trying to understand how the below works in Linux:

What happens when you fork() from one of the created threads?

  • what happens to other threads?

What happens when you fork() from the main thread (the thread/process calling fork)?

  • What happens if the main thread/process has multiple threads running? Does all the threads get duplicated too?

In both the above cases, where is the SIGCHLD signal sent to when the forked child process terminates?

user3479915
  • 5
  • 1
  • 4
  • 3
    Have you read `man fork`? *The child process is created with a single thread—the one that called fork().* – n. m. could be an AI Jan 08 '22 at 21:18
  • SIGCHLD is no different from most other signals. It is sent to the process as a whole, and delivered to a single arbitrarily chosen thread that doesn't have it blocked. – n. m. could be an AI Jan 08 '22 at 21:25
  • 1
    Stay safe! Stay sane! Don't call fork() after your program has created new threads. In one place I worked, we had a huge, multi-threaded program that needed to create helper processes from time to time. What we did was, when the program first started up, before it created any threads, it spawned a very simple, single-threaded service. Then, it created its threads. After that, whenever it needed to fire up a helper program, it asked the simple service to do it. The service included means to connect pipes between the main process and the helpers. – Solomon Slow Jan 08 '22 at 23:00
  • The initial thread of a process is special relative to other threads only in the sense that it is possible for that thread to `return` from the process's initial call to `main()`. Doing so has the effect of terminating the whole process. It is not a special kind of thread; rather, it just happens to be running code that has those particular semantics. Which thread starts which has no inherent semantic significance. – John Bollinger Jan 10 '22 at 16:08
  • @SolomonSlow "Don't call fork() after your program has created new threads." Is there an explanation for this? – Rom098 Feb 07 '23 at 17:36
  • @Rom098, Are you asking for an explanation of why Linux is the way it is? I'd _guess_ it's mostly historical. Linux originally did not have threads. They originally were added by generalizing the notion of what "process" meant. At that time, every thread occupied one slot in the process table, and it's thread ID actually was a process ID... OTOH, if you're asking why fork()ing a threaded program is a Bad Idea, it's what N.M. said in the first comment, above: In the child, it's as if all of the threads but one were abruptly killed. Killing a thread always is a Bad Idea. – Solomon Slow Feb 08 '23 at 19:06
  • P.S., I'm not really the expert here. I lost interest in Linux a few years back when I switched from writing code for data centers to writing code for medical devices and other small appliances. For all I know, maybe `fork()` followed immediately by `exec(...)` is OK, but I'm not going to be the one who tells you it's OK. \[Note: `vfork()` in a multithreaded program apparently is _not_ OK. Read the [man page](https://man7.org/linux/man-pages/man2/vfork.2.html), and search for "thread."\] – Solomon Slow Feb 08 '23 at 19:12

0 Answers0