This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients exarkun, neologix, r.david.murray, spiv
Date 2010-04-15.18:25:28
SpamBayes Score 1.3161147e-08
Marked as misclassified No
Message-id <>
> * There seems to be no good reason to special case SIGCHLD in signal_handler.  The comment about infinite recursion has no obvious interpretation to me.  Fortunately, this is irrelevant on platforms with sigaction, because the handler remains installed anyway!

I think that it's possible, on certain systems, that setting a signal handler for SIGCHLD while there is un unwaited child (zombie) process triggers a new sending of SIGCHLD.
"The SIGCHLD or SIGCLD were used for implementing job control.
Since I had implemented job control for both BSD and System V,
I pointed out to the standards group that except for SIG_DFL,
these signals had different semantics.

If a signal handler was set for SIGCLD, then a signal would
be generated if there were any unreaped child processes.
When the signal handler was caught in System V, it was reset
by default to SIG_DFL.  However, if a process did not
reap a child and instead reestablished the signal handler,
it would go into an infinite loop since the signal would
be generated again.  The SIGCLD SIG_IGN behavior was that
the system reaped the child when it completed so
that the application didn't have to deal with it.
However, I believe that a process blocked in wait() would
be awakened, but I am not certain of this.

The SIGCHLD signal on the other hand was generated when
a child completed if a signal handler was set at that time.
No signal would be generated if a signal handler was
established while there was waiting children.
The SIGCHLD signal was also generated when a child process stopped.
I believe that BSD treated SIGCHLD SIG_IGN the same way
that it treated SIGCHLD SIG_DFL."

So, there might exist out there a couple systems that merrily mix SIGCLD and SIGCHLD, and re-raise a SIGCHLD when setting a new handler for it when unwaited children exist (which is the case in signal_handle, since child processes can't be waited for before the main thread gets to execute the handler it set up).
Date User Action Args
2010-04-15 18:25:31neologixsetrecipients: + neologix, spiv, exarkun, r.david.murray
2010-04-15 18:25:31neologixsetmessageid: <>
2010-04-15 18:25:29neologixlinkissue8354 messages
2010-04-15 18:25:29neologixcreate