Messages in this thread |  | | From | Mark.Hemment@uniplex ... | Date | Wed, 19 Jun 96 11:00:59 +0100 | Subject | Re: On SIGCHLD signal semantics |
| |
Marc wrote: > On Tue, 18 Jun, Theodore Y. Ts'o wrote: >> POSIX explicitly specifies how signals should be inherited across an >> exec(), and your sugestion violates the POSIX requirements.
> I think the applicability of this requirement to SIGCHLD was an > oversight on POSIX' part, because always setting SIGCHLD to SIG_DFL > on exec would certainly solve a lot of portability problems.
I don't believe it was an oversight. POSIX knew what they were doing, and simply avoided the issue. If they had made a decision it would have broken the previous behaviour of either System V or BSD.
> BSD applications have no need to save/restore inherited SIGCHLD > handlers (because SIG_IGN == SIG_DFL).
My BSD 4.4 Programmer's Manual, states; "Execv(2)...Ignored signals remain ignored;" Your suggestion would break BSD as well as System V :)
System V probably regrets overloading SIG_IGN for SIGCHLD. In SVR4, they have an sa_flag; SA_NOCLDWAIT. This gives the same behaviour as as SIG_IGN for SIGCHLD.
Are the sa_flag's preserved over an execve(2)? In linux, they are not. In BSD4.4, the SA_RESTART flag is - not too sure about the other flag bits. Some SVR4 derived systems I've tried do not preserve the sa_flag.
It would make sense to preserve some; SA_RESTART SA_NOCLDWAIT SA_NOCLDSTOP
markhe
|  |