Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ctrl-C

kevinlawler.com

Post reply on HN
Print view View original

51–60 of 94 posts

Re: Ctrl-C

#51

Post by klez »

M9HF8wwiaAdZKEZ wrote: post #43
klez wrote: post #16

Earlier quoted context omitted.

That's the point: Ctrl-C shouldn't just gracefully kill the process, it should interrupt the current computation and let you resume your work without exiting the application. The use case here is interactive applications (think a REPL, for example), not commands you run, simply expect an output from and then they just exit (like, say, curl).

> it should interrupt the current computation and let you resume your work without exiting the application That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. If you want to be able to "resume your work" then you should press Ctrl+Z. If you want something else then the application should probably be listening for some other key…

> That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application.

If that's not how it should behave, how come any REPL I have handy handles Ctrl-C the exact same way? i.e. it doesn't exit the interpreter, it gets me back to the REPL. You can try yourself by getting stuck in a while loop and pressing Ctrl-C

Python (3) does it;

jshell does it;

guile does it;

csi (chicken scheme) does it;

sbcl does it;

bash does it

Re: Ctrl-C

#52

Post by krallja »

M9HF8wwiaAdZKEZ wrote: post #41

As far as I can tell, this appears to be confusing Ctrl+C (SIGINT, which terminates a process, and is usually not restartable), with Ctrl+Z (SIGTSTP, which pauses a process, and is thus restartable). The only software I can think of that could "restart" after a Ctrl+C is usually daemons or other long-lived processes (which already need to be able to "restart" after any kind of shutdown and thus have significant amoun…

No, you misread the article.

Open a Ruby interpreter (`irb`). Type `i=0; loop { i += 1 }`. Press Ctrl+C.

* Irb is still running.

* Your infinite loop has been stopped.

Type `i`:

* The REPL state preserved as much progress as it could when you aborted the run.

Now do the same thing in `sh`. Now `python`. Now `psql`. All handle Ctrl+C in the way the article mentioned!

Re: Ctrl-C

#55

Post by kcl »

xyzzy_plugh wrote: post #15

This makes no sense. Ctrl-C is just a way to tell your terminal to send a SIGINT signal to the current process. How that process handles the signal is up to it! It's by definition ignorable, as the author points out, but it's not rocket science to handle it in a sane fashion even in a multi-threaded application. Modern languages make this trivial. The author makes it sound like some dark art but in reality you just h…

There is an entire world here beyond registering for a signal that comment seems unaware of. Even the simplest of preliminaries: registering for a signal is arguably non-trivial and incorrectly specified in many places since sigaction() supersedes signal().

> it's not rocket science to handle it in a sane fashion even in a multi-threaded application. Modern languages make this trivial. The author makes it sound like some dark art

Which language? I'll specify one so we can begin the process of picking each apart. Python? There is a sibling thread indicating Python issues. I don't know what the actual internal status is with Python signal handling but I am guessing the interpreter actually doesn't handle it correctly if I spent any time digging. Do you mean apps implemented in Python? They will almost certainly not be internally data-consistent. Exposing a signal handling wrapper means very little particularly when they frequently do this by ignoring all of the bad implications. I just checked Python's docs, and not surprisingly, Python guarantees you'll be stuck in tight loops: https://docs.python.org/3/library/signal.html That's just one gotcha of many that they probably aren't treating. This dialogue is going to play out the same way regardless of which language you choose.

Do you mean Postgres? I haven't used it recently but the last comment I read on HN seemed to indicate you needed to kill it in order to stop ongoing queries in at least some situations. If by a stroke of luck it does support SIGINT recovery (which would be great), what about the hundreds of other db applications that have appeared recently? You can't just call the signal handler wrapper and declare victory.

Re: Ctrl-C

#56

Post by gfodor »

klez wrote: post #16
codethief wrote: post #9

> We don't want our ctrl-c to leak memory. […] If you allocate a piece of memory, you need to store a pointer to that memory from the object graph, and both of those operations need to occur inside of a critical section. Otherwise, if you get interrupted right after the allocation, there won't be any way to reach your memory and it will leak. Maybe I'm missing something here but… so what? If at the end of your Ctrl+C…

That's the point: Ctrl-C shouldn't just gracefully kill the process, it should interrupt the current computation and let you resume your work without exiting the application. The use case here is interactive applications (think a REPL, for example), not commands you run, simply expect an output from and then they just exit (like, say, curl).

The article’s point is basically proven by how many people here don’t even understand he’s talking about this, and not killing the program with Ctrl-C.

Re: Ctrl-C

#57

Post by mattarm »

wruza wrote: post #47
M9HF8wwiaAdZKEZ wrote: post #41

As far as I can tell, this appears to be confusing Ctrl+C (SIGINT, which terminates a process, and is usually not restartable), with Ctrl+Z (SIGTSTP, which pauses a process, and is thus restartable). The only software I can think of that could "restart" after a Ctrl+C is usually daemons or other long-lived processes (which already need to be able to "restart" after any kind of shutdown and thus have significant amoun…

This article is quite a roller coaster to get what it is about. As far as I understand it, the author wants SIGINT to become some sort of a universal “cancel” button which may or may not exit a process, because the idea is to stop and rollback to a nearest sensible restart point. E.g. an interactive disk formatting tool may stop lenghty formatting on SIGINT but wouldn’t just exit. It would clean up the mess and retur…

Yeah, and as others have pointed out already, many existing interactive terminal programs handle SIGINT in this way. E.g. programming language repls interrupt running code and return to the top level prompt. E.g. mutt (SIGINT will cause mutt to politely asks if you want to exit before doing so).

I think of it this way: we have both SIGINT and SIGTERM for a reason. One "interrupts" and the other "terminates" and there are often good reasons to handle "interrupt" differently from "terminate" -- at least in interactive programs.

Re: Ctrl-C

#58

Post by thayne »

krallja wrote: post #52
M9HF8wwiaAdZKEZ wrote: post #41

As far as I can tell, this appears to be confusing Ctrl+C (SIGINT, which terminates a process, and is usually not restartable), with Ctrl+Z (SIGTSTP, which pauses a process, and is thus restartable). The only software I can think of that could "restart" after a Ctrl+C is usually daemons or other long-lived processes (which already need to be able to "restart" after any kind of shutdown and thus have significant amoun…

No, you misread the article. Open a Ruby interpreter (`irb`). Type `i=0; loop { i += 1 }`. Press Ctrl+C. * Irb is still running. * Your infinite loop has been stopped. Type `i`: * The REPL state preserved as much progress as it could when you aborted the run. Now do the same thing in `sh`. Now `python`. Now `psql`. All handle Ctrl+C in the way the article mentioned!

So what is an example of an application that doesn't do this, that you would want to?

Re: Ctrl-C

#59

Post by snet0 »

M9HF8wwiaAdZKEZ wrote: post #43
klez wrote: post #16

Earlier quoted context omitted.

That's the point: Ctrl-C shouldn't just gracefully kill the process, it should interrupt the current computation and let you resume your work without exiting the application. The use case here is interactive applications (think a REPL, for example), not commands you run, simply expect an output from and then they just exit (like, say, curl).

> it should interrupt the current computation and let you resume your work without exiting the application That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. If you want to be able to "resume your work" then you should press Ctrl+Z. If you want something else then the application should probably be listening for some other key…

You might have killed enough programs with Ctrl-C, but SIGINT is an interrupt, not a kill, terminate or quit.

Re: Ctrl-C

#60

Post by jesprenj »

Even though it makes sense from the name, SIGINT, to interrupt, I've rarely seen console software "return control" to the user when the signal is received.

What I've mostly seen in programs is a clean exit from the running application, if live user input is not intended to be used. Clearing a line or something similar like redrawing the terminal (that's mostly Ctrl-L though) is what interactive programs do, let's say shells or ncurses UI programs.

Whenever I made some hobby scripts that exit cleanly when receiving a SIGINT, I've made a global counter of interrupts. When SIGINT is received, the counter is incremented, which tells the main loop to stop as soon as possible. But if this counter exceeds three signals, the application would exit immediatley. This may not be ideal, but CTRL-C CTRL-C CTRL-C is easier than kill -9 `pgrep a.out`.

Like the top comment says, expecting a concrete and general behaviour on different types of software for such a broad signal doesn't gain wide approval.

What "return of control" did the author mean, on what kinds software?

Post reply on HN