Re: Sane exit from a program on receipt of a signal

>>> As for SIGTSTP and other tty signals, the
signal should be sent to
>>> the process group rather than to just the
current process.
>> I disagree.
> Take a look at curses(3) and other SIGTSTP-aware
software.  You will
> easily find kill(0, SIGTSTP).

So?  Just because other software is broken is no reason for
us to write
more broken software.  (I wasn't aware of this bug in
curses; it really
ought to be fixed.  Thanks for pointing it out.)

> Stopping only one process of a process group will cause
serious
> problems with BSD job control and must be avoided.

Right.  So?  As I wrote, if it was generated from the tty,
it's already
been sent to the rest of the process group.  If it was
generated with
kill(), then either it's already been sent to the rest of
the process
group or it shouldn't be sent to the rest of the process
group.

> BSD is carefully designed to allow kill(0, SIGTSTP) in
the former
> case.  Sending SIGTSTP to already stopped processes is
ignored
> happily.

Yes...if the process happens to be stopped at that point. 
Which it may
not be, for any of various reasons.

> In the latter case ["If it was sent to this
process specifically"],
> stopping one process of a process group may left the
terminal in
> unusable state, and stopping the process group is
user's benefit.

That's as may be.  But it is not for us to make that
decision; that is
for the signal's sender to decide.  If the signal was sent
to us and no
other process, it is not for us to say that it should be
rebroadcast to
others; we should behave as much as possible like a process
with no
handling installed, which does *not* include re-sending the
signal
anywhere.  "Unix does not prevent you from doing stupid
things because
that also prevents you from doing clever things."

/~ The ASCII				der Mouse
 / Ribbon Campaign
 X  Against HTML	       mouserodents.montreal.qc.ca
/  Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3
27 4B