lkml.org 
[lkml]   [1996]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2011 Jasper Spaans