>> The oddity of the current situation is that the signal handlers are
>> removed at exec time, but the signal delivery masks are left in
>> place.  What use is it to have a delivery mask for a signal with no
>> handler?

twofsonet@graffiti.com replied to this with

> der Mouse gave a rather excellent argument for this behavior, which i
> accept completely.  [...]  perhaps he'd like to repost it here?

What I thought I was arguing for was not the behavior referred to in
the double-quoted text above but rather the behavior of inheriting the
blocked-signal mask of the process - not the block-on-delivery masks
associated with signals that could at some future point be delivered to
the process - from the previous image.  (My argument amounted to the
"UNIX does not stop you from doing stupid things because that would
stop you from doing clever things" truism.)  And when ross@teraflop.com
writes

> Although there are certainly many reasonable arguments against
> inheriting quite so many attributes, Posix 1003.1 make it very clear
> that the process signal mask is inherited from the old image.

I feel certain "the process signal mask" refers to the mask of signals
currently blocked for delivery.  Nobody is (now) questioning the
inheritance of *that* mask across an exec.  What is being discussed is
inheritance of the other masks, one associated with each
potentially-deliverable signal, the masks that specify what signals are
to be automatically blocked upon signal delivery.

To put it another way, we're talking about the sa_mask fields of the
structs sigaction corresponding to the various signals (there's one
such field per signal per process), not the mask that	
sigprocmask(SIG_SETMASK,...) bashes (of which there's only one per
process).  The former sometimes affect the latter during signal
delivery, but they are otherwise unrelated.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B