Re: Is wait not interruptable?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 15, 12:05pm, Peter Stephenson wrote:
}
} > The ^C was typed 1 second after the command was 
} > started, and the first sleep plodded along to completion for its full 
} > 3 seconds.
} 
} I *think* the patch below fixes (b) by sending SIGHUP to our own process
} group when exiting from a non-interactive shell, but I'll take advice on
} this.  (I can at least then get the test program to work with "setopt hup
} trapsasync".)  The manual isn't clear over whether this is supposed to
} happen non-interactively, though it would probably be fair to assume

This is a conflict between subshells and other non-interactive shells.  I
believe a subshell whose parent is an interactive shell should propagate
HUP signals to any tasks that it backgrounded, but shells that are non-
interactive from the get-go should not.

This has to do with the defnition of SIGHUP, which is that it's a signal
sent by a controlling TTY to the foreground process group leader when the
TTY is disconnected.  Shells that are not a foreground group leader are
not responsible for propagating HUP signals.

This is of course all a mishmash from the way shells work.  If a shell
has started a foreground job and given that control of the TTY, then
when the line drops the foreground job will get HUP'd but the shell
will not -- it'll just get EOF after it reaps the foreground job and
goes back to read from the terminal again.  Generating a HUP to all its
other jobs in that circumstance is just to mimic the behavior of the
OS signalling the whole process group, which would have happened if the
shell had been the foreground job at the time of the hangup.

} if HUP is set in a non-interactive shell you'd expect the SIGHUP to be
} sent.

Well, yes and no.  In a non-interactive shell there is theoretically no
controlling TTY, so there's no reason to expect to receive a HUP in the
first place, so no reason to expect it to be sent either.

[In another message]

} TRAPSASYNC was really introduced, as the name suggests, to affect trap
} execution (see second paragraph of the section in the URL), not the
} point at which the signal is delivered to the shell, but in practice it
} does the former by altering the latter.  The may be a case for always
} handling the signal immediately and altering the code only to delay any
} traps.  But I'm still not sure why it's done the way it is.

The signals are handled the way they are mainly because of non-re-entrant
libraries (particularly malloc) that can be confused or broken by having
signal code executed at an arbitrary point.  The "wait" builtin should
probably set TRAPS_ASYNC implicitly during its execution, based on the
text in 2.11 at that POSIX URL you indicated.