bug-bash
[Top][All Lists]
Advanced

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

Re: [BUG] Bash not reacting to Ctrl-C


From: Linus Torvalds
Subject: Re: [BUG] Bash not reacting to Ctrl-C
Date: Mon, 7 Mar 2011 09:11:28 -0800

On Mon, Mar 7, 2011 at 8:45 AM, Chet Ramey <chet.ramey@case.edu> wrote:
>
> The one thing that jumps out at me here is the number of signal-handling
> system calls.  wait_sigint_handler gets installed and removed as the
> SIGINT handler a lot.  I wonder if we would see an improvement if I
> used a global SIGINT handler that understood what to do with
> wait_sigint_received.  That's a change for down the road.

Signal handling is a pain. There's a reason people hate UNIX signals.
It's damn well nearly impossible to handle signals well and without
races.

Many server applications in particular end up basically exposing them
as synchronous events rather than as signals, and it's why we have all
the crazy "pselect()" etc extensions to various waiting system calls
to say "I want to wait for events and still be interrupted by signals,
but I want to then actually *handle* the signal synchronously". And
they often do it for efficiency reasons - exactly so that they can
avoid the cost of blocking and unblocking them all the time around
critical regions.

But even if there was some "pwait()" system call interface, I don't
think it would really help this particular problem. You might be able
to avoid a system call or two (and that would look prettier in
traces), and some things might be faster (which is why the server
people do it) and might be easier to understand (asynchronous events
are just painful as hell). But the fundamental issue is still simply
that the whole situation is ambiguous.

It really isn't possible to tell the difference between "somebody
blocked SIGINT and then returned success later _despite_ the SIGINT"
and "somebody returned successfully before SIGINT even happened".

Except for timing. The "catch EINTR" was a try at catching a timing
issue: "did we see the dead child before we saw the SIGINT". And I
think it's why it works pretty well (I really had to do quite a lot of
testing to catch the lost ^C behavior with that patch - in contrast,
with your latest patch I think I caught it on the fifth or sixth try).

Painful.

                      Linus



reply via email to

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