Messages in this thread |  | | Date | Tue, 4 Jun 1996 18:41:15 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: 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
|  |