Tim Hockin <thockin@isunix.it.ilstu.edu> writes:
> I don't have POSIX at hand, but does it not also specify exec() from a
> signal handler is OK? I am pretty sure it does.
execle() and execve() only.
> In this case, the
> new image has the "current" signal blocked. Is this proper? It seems
> obtuse that a process would have to do sigemptyset() and sigprocmask()
> before exec().
>
> comments? should we perhaps clear the 'current' signal from the mask,
> or is that just overinterpreting?
Here's a paragraph from the rationale for exec*():
POSIX.1 specifies that signals set to SIG_IGN remain set to SIG_IGN
and that process signal mask be unchanged across an exec. This is
consistent with historical implementations, and it permits some useful
functionality, such as the nohup command. However, it should be
noted that many existing applications wrongly assume that they start
with certain signals set to the default action and/or unblocked. In
particular, applications written with a simpler signal model that does
not include blocking of signals, such as the one in the C Standard,
may not behave properly if invoked with some signals blocked.
Therefore it is best not to block or ignore signals across execs
without explicit reason to do so, and especially not to block signals
across execs of arbitrary (not closely co-operating) programs.
So the committee knew about the problems, and wanted this behaviour
anyway. But friendly programs shouldn't do an exec with blocked
signals, and robust programs shouldn't assume that they are started
with an empty sigal mask.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:19 EST