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

41–50 of 94 posts

Re: Ctrl-C

#41

Post by M9HF8wwiaAdZKEZ »

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 amounts of code dedicated to serializing and unserializing their internal state).

TFA even goes so far as to talk about memory leaks - which are completely irrelevant when your process is about to exit anyway!

Re: Ctrl-C

#42

Post by ruslan »

Just wonder if author is aware of SIGSTOP/SIGCONT that allows to pause/resume any process gracefully ? Both signals can be caught and handled.

Crtl-C (SIGINT), as far as I know, was used to "gracefully terminate" interactive process from day zero of Unix. I cannot find any use in that of what author proposes: suspend execution by sending SIGINT, but then what ? Get to some process built-in debugging shell ? Isn't that what GDB was made for ?

Re: Ctrl-C

#43

Post by M9HF8wwiaAdZKEZ »

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).

> 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 keystroke. "Catch Ctrl+C and do something else" is a pretty awful idea for the very reason mentioned at the top of TFA (when you press Ctrl+C, it's to get out of whatever you're stuck in, so that you don't have to go open another terminal and type in killall ...)

Re: Ctrl-C

#44

Post by FeepingCreature »

cryptonector wrote: post #27
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…

> it's not rocket science to handle it in a sane fashion even in a multi-threaded application It's not, though you need to be careful if you want to exit cleanly -- you can't just exit() or _exit(). You have to get all the threads to exit, and that requires a global volatile sig_atomic_t flag and some way to signal all threads that might be sleeping in event loops or what have you.

Sure you can just exit(), you just have to be sure that all your on-disk state changes are atomic. Which you should make sure of anyways.

Re: Ctrl-C

#45

Post by M9HF8wwiaAdZKEZ »

awild wrote: post #35
dmarinus wrote: post #3

After decades of experience I learned to use ctrl-\ (break) or ctrl-z and then kill -9 %1. Hope this helps someone.

Kill9 can keep ports locked for a bit after exiting which is a quite annoying

Anything can keep ports locked for a bit (if either side doesn't properly close the connection). That's how TCP works. Set reuseaddr on your daemon's sockets.

Re: Ctrl-C

#46

Post by vermilingua »

dgfitz wrote: post #30
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).

IMHO anyone launching an app via a terminal and Ctrl-C killing it either is developing the app (in which case they can manage the signal however they like) or they don’t care and just want the app to die. Any “good” repl won’t let you exit via Ctrl-C so that point is moot.

> Any “good” repl won’t let you exit via Ctrl-C

And in order to achieve that, it has to take the care described in TFA.

Re: Ctrl-C

#47

Post by wruza »

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 return to its menu where e.g. batch configuration happens, so a user doesn’t lose next steps. The author basically wants modern gui features in console via signals.

Re: Ctrl-C

#48

Post by macleginn »

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.

I spend a lot of time running computations in REPL, and sometimes I realise that I made a mistake and I don't want to wait for the current operation to complete, or the mistake itself is such that the operation will complete only after I become old and die. In this case, I expect Ctrl+C to abort the current computation and return to the REPL, with the previous state (all the variable assignments) intact (modulo assignments made inside the loop I killed). I think a lot of people have the same expectation, and it's usually satisfied in modern REPLs.

Re: Ctrl-C

#49

Post by duped »

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…

If the application is a shell or REPL (an application running other programs) then that is exactly what you want to use CTRL-C for.

Re: Ctrl-C

#50

Post by quietbritishjim »

cryptonector wrote: post #27
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…

> it's not rocket science to handle it in a sane fashion even in a multi-threaded application It's not, though you need to be careful if you want to exit cleanly -- you can't just exit() or _exit(). You have to get all the threads to exit, and that requires a global volatile sig_atomic_t flag and some way to signal all threads that might be sleeping in event loops or what have you.

A separate thread with sigwait() may be easier. Though I must admit, I've rarely had to do that manually, as I'm usually using a language or framework that gives an easier way to get notified about signals (e.g. Python KeyboardInterrupt or listeners in Boost ASIO or libuv). Aside from saving some boilerplate, those also emulate equivalent signals in Windows.

Threads waiting on event loops is exactly what you want on shutdown: that's what you use to notify them to exit.

Post reply on HN