|
|
|
|
|
|
by gwright
987 days ago
|
|
|
I'm a little rusty here, but I think you are talking about the fact that the exit status of the child process has to remain available until the parent process can reap it. Until that happens the child process is in the zombie state. You indicated that the creating thread needed to exit, but that seemed a bit too specific to me, I think that any thread can reap the exit status of a child process. Related to this is the double-fork pattern to avoid zombie processes (and a couple other issues) when initiating a daemon process. |
|
|
The parent process was an event loop based python program whose main function was to manage the creation and deletion of these child processes, and the simplest way to spawn child processes without blocking the event loop is to call fork(2) on a thread pool. My thread pool was triaging the number of worker threads based on demand, so occasionally it would decide a worker was no longer needed, and all the child processes that happened to have been created on that thread would get SIGKILL'd — something you rarely want when using a thread pool!
I didn't want the child processes to die unless the parent process's business logic decided they were no longer needed, or if the parent was itself killed (this latter reason being the motivation for setting PDEATHSIG).
Once I understood why my processes were dying, the solution was simple: make sure the worker threads never exit.