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

[konsolebox]

On Fri, Oct 11, 2013 at 10:06 PM, Chet Ramey <chet.ramey@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.

Examining further with the following script I find that most signals are
handled with no problem besides SIGKILL and SIGCHLD which is a practical
thing or something that can't really be bypassed but I don't see the reason
for SIGCHLD and how other signals would really differ from it. Even if
SIGCHLD traps could receive signals most of the time due to child processes
exiting, couldn't that be possible with other signals as well? Or does this
mean that we should avoid IPC through signal handling completely?

safe_exit() {
    echo "Do safe exit routines."
    echo exit 0
}

for (( I = 1; I <= 31; ++I )); do
    [[ I -ne 9 && I -ne 19 ]] && trap safe_exit "$I"
done

(
    for (( I = 1; I <= 31; ++I )); do
        [[ I -ne 9 && I -ne 19 ]] || continue
        sleep 1s
        echo "Sending $I."
        kill -s "$I" "$$"
    done
) &

echo "Interacting."

read

For scripts handling one-key input there's an easy workaround with it
through loops with 1-second interval which doesn't really affect my program
but it would be a problem to scripts that read user input line by line.

SIGCHLD is really a very useful signal so I hope it would be reconsidered.

Cheers, konsolebox