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


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