Proper handling of SIGINT/SIGQUIT (2013) | Hacker News Reader

Proper handling of SIGINT/SIGQUIT (2013)

cons.org

43 pointsteddyh15 comments

Abstract:

In UNIX terminal sessions, you usually have a key like C-c (Control-C) to immediately end whatever program you have running in the foreground. This should work even when the program you called has called other programs in turn. Everything should be aborted, giving you your command prompt back, no matter how deep the call stack is.

Basically, it’s trivial. But the existence of interactive applications that use SIGINT and/or SIGQUIT for other purposes than a complete immediate abort make matters complicated, and – as was to expect – left us with several ways to solve the problems. Of course, existing shells and applications follow different ways.

This web page outlines different ways to solve the problem and argues that only one of them can do everything right, although it means that we have to fix some existing software.

I'm curious, isn't there a race condition in the WCE method, where:

(1) The child terminates normally, never having received SIGINT.

(2) The parent receives SIGINT before it reaches the wait() call, or while in the wait() call but before the child termination is picked up (I suppose in the later case wait() might fail and be restarted).

(3) Once the parent sees that the child terminated normally, it does not exit, and SIGINT was effectively ignored.

I don't see a race -- the article says: "Take no action when SIGINT is received while you wait for a child. You make a note of the fact that you did receive it, though."

Then, after waiting on the child, "Look at whether you (the shell) has received SIGINT while the child was in the foreground", and the shell kills itself with SIGINT if so.

Many times I've had to Control-Z a process (suspend it) and then kill it, because Control-C did not propagate correctly. And even then, the kill usually required a "kill -9".

It would be great if consistent interruption could be solved once and for all. In many cases, the presence of sub-processes is essentially an "implementation detail" of the program you're trying to interrupt but you just don't know if the Control-C will work or if the shell will just sit there and hang. And many people are not aware of what shells can do either so they try even more extreme things like closing entire terminal windows to cope.

The cvsweb links are semi-broken. Relevant SVN commit: http://v4.freshbsd.org/commit/freebsd/src/38520

I had to look it up, since it is so rarely used: Sigquit is often mapped to ctrl-\

Also, “Ctrl-\” (and hence SIGQUIT) is often also available as “Ctrl-4”. This is especially useful in case your keyboard does not have the US keyboard layout, and has placed the ‘\’ character on a key combination which is hard to type.

Anybody want to come up with a year for this one? https://web.archive.org/web/*/http://www.cons.org/cracauer/s... is daunting.

First archive entry is from 1999, but it seems to have been continuously updated since.

Right, but the 1999 version is substantively different, so we probably shouldn't make that the year, so what year should we give it?

Sorry, I know this is off-topic shop talk, but we do these all the time and this one is unusual in its non-obviousness. I'll try to resist posting more about it.

What year to you attribute a Wikipedia article to?

The idea that a web page has a definite year it was written in is a very blog-centric (or should I say a newspaper-centric) view. Web pages can be more than that.

Can be, but the vast majority of stories posted to HN aren't hard to put a year to.

It's 2013; see the modification date at the bottom.

It depends on how big the modification was. We're looking for the year the article was written, not when it was last tweaked.

Thanks; title edited.

Reply on news.ycombinator.com