Re: Bash 4.3 no longer handles traps when reading input with read

[Chet Ramey]

On 10/11/13 2:47 AM, konsolebox wrote:
> Good day,
> 
> It seems like starting 4.3 (beta2) bash already delays handling traps until
> read exits. Is this intended? It would be a problem if read has a long
> timeout or doesn't have a timeout at all:

This is part of a significant rewrite of trap handling beginning after
bash-4.1 was released and continuing through bash-4.2.  Traps should be
run at command boundaries.  Bash used to run certain traps asynchronously,
whenever they arrived, which resulted in running too much code in a signal
handler context and occasionally corrupting internal shell state.  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.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/