The python signal handlers do not seem to be real signal handlers; that is they happen after the fact, in the normal flow and after the C handler has already returned. Thus you’d try to put your quit logic within the signal handler. As the signal handler runs in the main thread, it will block … Read more
No, by default, most signals cause an immediate, abnormal exit of your program. However, you can easily change the default behavior for most signals. This code shows how to make a signal exit your program normally, including calling all the usual destructors: #include <iostream> #include <signal.h> #include <unistd.h> #include <cstring> #include <atomic> std::atomic<bool> quit(false); // … Read more
signal isn’t the most reliable way as it differs in implementations. I would recommend using sigaction. Tom’s code would now look like this : #include <signal.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> void my_handler(int s){ printf(“Caught signal %d\n”,s); exit(1); } int main(int argc,char** argv) { struct sigaction sigIntHandler; sigIntHandler.sa_handler = my_handler; sigemptyset(&sigIntHandler.sa_mask); sigIntHandler.sa_flags = 0; … Read more
I have done some research around this topic, which turned out to be more popular than I anticipated. KindDragon’s reply was one of the pivotal points. I wrote a longer blog post on the topic and created a working demo program, which demonstrates using this type of system to close a command line application in … Read more