I don’t think I’ve ever encountered a CLI application which I couldn’t kill with ^C other than defunct processes
Ctrl-C
11–20 of 94 posts
Re: Ctrl-C
#12I feel this. Signal handling in Python code is especially complicated. I'm not even talking about multithreading here (not like you get anything out of it anyway).
Python registers POSIX signal handlers, that upon SIGTERM/SIGINT, set a flag. Next time the interpreter loop runs, the flag is checked before the next instruction is being run and the stack is unwinded.
When you call out to some C code, that C code may run for a long time. During that time, there is no interpreter loop actually looping. Therefore, all signals are ignored in principle while C code runs.
It's possible for Python code to become uninterruptible while it is calling something like pthread_join.
See https://stackoverflow.com/questions/39930722/how-do-i-catch-...
Then of course, you have that on top of all the other problems mentioned by the blogpost.
Re: Ctrl-C
#13I don’t think I’ve ever encountered a CLI application which I couldn’t kill with ^C other than defunct processes
vi?
Re: Ctrl-C
#14I'm confused. Which software is he talking about? I can't think of any program screwing up Ctrl-C in a bad way.
Re: Ctrl-C
#15This 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 have to read the manpages.
SIGINT is really designed for interactive applications. Most processes should simply treat it like a SIGTERM unless they have some sort of REPL. Unless you need graceful shutdown, most processes shouldn't mask either signal. If they do, the polite thing is to unmask after receiving the first signal so subsequent signals immediately terminate.
Re: Ctrl-C
#16> 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).
Re: Ctrl-C
#17I don’t have any expectations of a program doing an orderly shutdown and trying to avoid corrupting files on disk when interrupted by Ctrl-C.
Re: Ctrl-C
#18This 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…
> SIGINT is really designed for interactive applications.
Which are the applications the article is talking about anyway.
Re: Ctrl-C
#19I thought this was going to be another C++ replacement - actually not a bad name.
Re: Ctrl-C
#20I don’t think I’ve ever encountered a CLI application which I couldn’t kill with ^C other than defunct processes
it’s the prefix for user keybinds in emacs.
it shows the current line number in nano.
etc.