[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: Bash 4.3 no longer handles traps when reading input with read
Date: Fri, 11 Oct 2013 10:06:44 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]