Re: [PATCH] x86_64: fix delayed signals

Linus Torvalds
2008-07-13T17:33:19Z

On Sun, 13 Jul 2008, Andi Kleen wrote:
>
> At least the original report was about Ctrl-C only versus Ctrl-Z.

Yes, and I explained why.

> I see the problem regularly myself that Ctrl-C doesn't work,
> but Ctrl-Z+kill does (although I unfortunately cannot
> reproduce it on demand).

There's no way you _can_ reproduce it.

> But it was with programs who shouldn't catch Ctrl-C, like find.

No, it was not. I think you misread it.

Two facts:

- ^Z and ^C are both going to be equally fast if they aren't blocked.

This is just how things are. They are handled by the same codepaths.

- the report you point to does mention 'find', but *not* in the place
where it talks about "^Z+kill". There it's much less specific, and I
bet that Edwin _had_ seen the "^Z works" behavior, and knew it to be
true, but hadn't realized that it depended on the command, so when he
gave an example of something where disk IO makes signals slow, he
happened to pick one where ^Z and ^C were equally slow.

In other words, I can pretty much _guarantee_ that if ^Z+kill is faster
than ^C, then it's because the process blocked or caught ^C.

And I can pretty much also guarantee that when Edwin talked about 'find'
and did that ^C cut-and-paste, he didn't try the ^Z thing (that had
happened with _other_ programs), or if he did, it was just happenstance
(because the latency isn't _always_ 10-30 seconds - that's just the worst
case).

So yes, ^C often works slower. If the process catches it and removes
temporary files as a result (for example - it's what things like gcc do),
then of _course_ it's going to be slower. It's going to be very noticeably
slower, especially since removing a temp-file is going to be even more
likely to hit a filesystem lock if the write-queues are full than just a
normal read is.

But ^C isn't always slower, and if 'find' doesn't block/ignore it (and I
certainly believe you when you say that it doesn't), then for the case of
'find', it won't be true that ^Z+kill is any faster.

In fact, Edwin later in this thread reported:

"Also I wasn't able to reproduce the 'Ctrl+Z works faster than Ctrl+C'
symptom, perhaps it is just a coincidence: by the time I press Ctrl+Z to
interrupt, enough time has passed (30+ secs), that the same effect would
have been obtained by another Ctrl+C, or by just waiting."

and I bet that is exactly because now he's been testing programs that
don't block ^C (ie maybe he's now testing _just_ that "find /" thing).

So before, Edwin was probably doing random things when doing "normal
work", and noticed that ^Z was sometimes faster. Now, he's trying to chase
things down, and he creates this specific test-case, and for that
particular test-case, ^Z _isn't_ faster. He just didn't pick up on the
pattern that it depends on which particular command he works on.

Try "yum list", and you'll certainly see that ^Z works a *lot* faster than
^C (and the latter often needs multiple ^C's even when there is no load
at all)

Linus