lkml.org 
[lkml]   [1996]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: On SIGCHLD signal semantics
   Date: Tue, 4 Jun 1996 15:13:38 -0600 (MDT)
From: Marc Aurele La France <Marc.La-France@UAlberta.CA>

So, because applications are, in general, not ensuring their SIGCHLD
signal handler is not SIG_IGN, the question boils down to: Should the
kernel do it for them (by always setting SIGCHLD to SIG_DFL on an exec
call)? In more general terms, is POSIX compliance the kernel's
responsibility? or is it the application's?

It's both. The kernel's responsibility is to implement according to the
POSIX spec. It's the application responsibility to not make any
assumptions beyond what POSIX allows, if the application is going to be
POSIX conforming.

In answer to your specific question, the kernel isn't allowed to modify
signal handlers to change SIG_IGN to SIG_DFL. (POSIX 3.1.2.2) That
would break other application who might quite legitimately want the
child to keep SIGCHLD at SIG_IGN.

Bottom line, applications that set their SIGCHLD signal handler to
SIG_IGN are broken, and should be fixed. If they are doing it because
they expect the System V semantics, then they will work under Linux, but
it won't be portable to other POSIX systems. Most of the time, though,
people who are setting SIGCHLD to SIG_IGN are just simply being ignorant
of POSIX's requirements.

- Ted


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.092 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site