On Mon, Oct 14, 2013 at 2:29 AM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 10/11/13 6:19 PM, konsolebox wrote: > > On Fri, Oct 11, 2013 at 10:06 PM, Chet Ramey <chet.ra...@case.edu > > <mailto:chet.ra...@case.edu>> wrote: > > > > The SIGCHLD handler was particularly bad, since children can die and > > interrupt > > the shell at any time. As an example, glibc uses internal locks > > extensively, especially within its malloc implementation, and > running trap > > handlers when a signal arrives (or worse, longjmping back to saved > state) > > caused deadlocks. > > > > The bash signal and trap handling is now much closer to the Posix > model: > > minimal work done when the signal arrives, traps run when it is safe > to > > do so. If the arriving signal causes certain system calls to return > > -1/EINTR, for example if a SIGINT interrupts read(2), bash will > notice and > > check for pending traps. SIGCHLD doesn't behave like that. > > > > > > Thanks for the reply. > > > > I understand the possible effect of receiving multiple signals at once, > but > > how are other signals different from it? If one would trap signals like > > SIGQUIT, SIGABRT, SIGINT, SIGHUP and SIGTERM for safe exitting of an > > interactive script e.g. during shutdown some of those signals could > arrive > > quickly as well. > > It's not a question of receiving multiple signals at once. It's a question > of running too much in a signal handler. Since Posix says you can only do > a certain small number of things in a signal handler, bash needs to do as > little as possible -- for both trapped signals and ones bash handles > internally -- and defer the real work until it's `safe'. In the case of > traps, this is generally at command boundaries. > > Bash-4.3 handles signals and traps when a read run by the read builtin is > interrupted by a signal. I'm not sure that's the best thing to do, > since traps should really be run when commands finish, but we're going to > try it. > > Since bash-4.2, bash has installed its SIGCHLD signal handler with > SA_RESTART, so a child death does not unexpectedly interrupt system calls. > There were several bug reports concerning this. So yes, SIGCHLD is > special. I'm not really able to comprehend the significance of SA_RESTART to SIGCHLD that it could affect the signal and make it behave differently from the other signals i.e. it can't be a good idea to allow interruption from it when in a read builtin context, but could it be possible that we allow it when not in posix mode? Probably it's about the variable posixly_correct. If we can allow at least just one interruption to happen maybe with the help of the variable running_trap it would really be good enough.
