Messages in this thread |  | | Date | Tue, 18 Jun 1996 16:34:47 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: On SIGCHLD signal semantics |
| |
Date: Tue, 18 Jun 1996 14:23:48 +0200 From: Michiel Boland <boland@sci.kun.nl>
>First, applications that set their SIGCHLD handler to SIG_IGN are not >inherently broken. They are simply expecting System V semantics.
But Linux is not System V. Linux is Linux. Ergo: these applications are broken. Full stop.
Well, to the extent that Linux is trying to provide System V compatibility, Linux can also be said to be broken. Yes, applications which assume System V behavior are not POSIX-complaint, and it would probably be better to make them POSIX complaint.
As far as improving Linux so that it can handle System V-style compatibility, yes we can do that but it would be rather tricky to do. I'll start looking at ways to accomplish this.
>One open question remains, and that is the advisability of causing child >processes to inherit SIG_IGN as their SIGCHLD signal handler (i.e. to do >an exec* syscall while ignoring child processes).
Perhaps the SIGCHLD handler can be reset to SIG_DFL across an exec, unless of course POSIX exlicitly forbids this.
POSIX explicitly specifies how signals should be inherited across an exec(), and your sugestion violates the POSIX requirements.
As for Marc's suggestion for treating inherited versus explicitly set SIG_IGN differently, other people have listed the many reasons why that's a bad idea. It violates the principal of least surprise; there might by System V applications that assume that you can inherit SIG_IGN; and if you save and restore a signal handler, it will look like a explicitly set signal handler, not an inherited signal handle.
- Ted
|  |