Chet Ramey writes ("Re: Want way to run background processes with SIGINT
unignored"):
> On 10/9/15 2:42 PM, Ian Jackson wrote:
> > However, it would be very easy for bash to provide an option (via `set
> > -o' perhaps) to disable this behaviour. That is, to allow SIGINT to
> > be delivered normally to child processes.
>
> I'm restricting non-standard options to `shopt' to avoid any possible
> conflict with future posix changes.
Right.
> > With such an option, scripts which run on modern systems and which
> > attempt to parallelise their work, would be able to arrange that ^C
> > properly cleans up the whole process group, rather than leaving the
> > background tasks running (doing needless work and perhaps causing
> > lossage).
>
> I'd be willing to look at a patch that implemented a new option to
> enable this. You only need one option; you only have two behavior
> modes and you're introducing one new behavior.
OK.
> > 2. In the child, reset SIGINT and SIGQUIT to the values found at
> > shell startup. That is, uninstall trap handlers. This is what
> > most ordinary scripts will want, because they don't want the trap
> > handler running in both parent and child. It's the same as is
> > done for all other signals, and for all signals in non-background
> > subshells and subprocesses.
>
> This is the behavior that any new option would toggle. Some name like
> `async_sig_ignore' or `async_sig_restore' would work.
Thanks for your attention and your feedback; I'll get back to you with
a patch.
FWIW I agree that Linda Walsh seems to be talking about something
different; I don't have a clear opinion right now about her
observations, but I don't intend to do anything about trying to
improve the area she's talking about:
Linda Walsh writes ("Re: Want way to run background processes with SIGINT
unignored"):
> no? they want to run background processes and not have
> the sig handlers mangled (and presumably that means getting the
> signals in real time -- not waiting for the users next keypress!)
With my proposed new option enabled, the affected signals (INT and
QUIT) would be set to DFL in the child. This will mean that the child
is terminated immediately by the kernel when the signal is sent. In
most cases, the programmer doesn't mind whether the resulting SIGCHLD
etc. for the parent is dealt with now, or later (when the parent
script calls the `wait' builtin).
> Requiring timely delivery of said signals, would be required for
> their use case of " a bash script which invokes a
> number of subprocesses in parallel and collects the output. ". If
> the foreground process is also waiting for user input to provide
> interactivity, will the SIGCHLD events come in when the children
> terminate or when the foreground process leaves readline?
I'm talking about noninteractive shells here. (Interactive shells
have job control, and their background children do not have INT
etc. ignored.) I don't think a noninterative shell is likely to be in
readline, although it might be waiting in `read', or for a foreground
subprocess to take user input, in which case when a SIGINT comes in
the parent's handling of the death of its background children will
indeed be delayed until the shell gets round to it. I think this is
fine (even, usually, desirable).
Regards,
Ian.
