SIGINT is used to handle Ctrl+c but there is no signal for Ctrl+n and Ctrl+d, how can I handle these? Any idea?
I have a link list in my program and I have to perform some link list operations in these signal handlers. I just want to detect Ctrl+d and Ctrl+n in the normal flow of program.
Related
Some programs pop "Save before exit?" message when terminating.
And I wonder if I can implement this with C++ console application.
So I tried some standard functions like signal and atexit.
But they only work when:
main() returns (atexit)
sending interrupt through Ctrl+C (on Windows, SIGINT)
an error occurs (SIGABRT)
So yeah, how? Is it only possible with GUI application?
In comments, you said:
I want exit events to happen when that 'X' button is pressed(On windows).
That's part of GUI I guess.
Than what kind of request is sent to program when the exit button of the console is pressed?
You can use SetConsoleCtrlHandler() to register a user defined callback function that receives a CTRL_CLOSE_EVENT notification when the console window is closed:
A signal that the system sends to all processes attached to a console when the user closes the console (either by clicking Close on the console window's window menu, or by clicking the End Task button command from Task Manager).
I am working on a TCP server that I'm developing on CLion under Windows 10.
I would like my program to be able to end properly, when I click on "stop" my program. I thought CLion was sending a signal, but after trying to catch them all, it looks like it does not.
So my question is, how does CLion stop running the program? Is it possible to detect it within the program?
Thank you in advance.
I found my answer here.
According to this link, signals are actually used :
Click this button to terminate the current process externally by means
of the standard shutdown script. Clicking the button once invokes soft
kill allowing the application to catch the SIGINT event and perform
graceful termination (on Windows, the Ctrl+C event is emulated). After
the button is clicked once, it is replaced with icon run tool window
kill indicating that subsequent click will lead to force termination
of the application, e.g. on Unix SIGKILL is sent.
I'm writing a console multi-process application in c++ using WinAPI. So I have the Dispatcher(e.g. "Parent") and the Client(e.g. "Child") processes. Both processes are synchronized: they're using semaphors, events, mutexes and the pipe (all of them are standard WinAPI handles). Application stop when the user type the "exit" command. If the user do so, the dispatcher process notifies it's child, and then child releases its resources and makes another before-exit procedures to exit correctly. But there's a thing that bothers me: what will happen if the user press the window "close" button? If so, I should listen to close event and then perform my resource-releasing procedure. What is the easiest way to handle window close event?
Write a console handler routine that detects CTRL_CLOSE_EVENT (and CTRL_C_EVENT, if desired), and use SetConsoleCtrlHandler to add the handler routine to your process.
It isn't really different from the client process crashing or being terminated through Task Manager. You ought to be resilient to that as well. The ultimate signal you get for that in the parent process is that the client's process handle will be signaled.
Use WaitForMultipleObjects, along with those other handles, to detect this.
I guess the question says it all, but, what happens if someone closes a c++ console app? As in, clicks the "x" in the top corner. Does it instantly close? Does it throw some sort of exception? Is it undefined behavior?
Closing a c++ console app with the "x" in the top corner throws an CTRL_CLOSE_EVENT which you could catch and process if you set a control handler using the SetConsoleCtrlHandler function. In there you could override the close functionality and perform whatever you wished to do, and then optionally still perform the default behavior.
I imagine that the console process just gets unceremoniously killed by the OS. If you want to trap this event and do something it looks like the SetConsoleCtrlHandler function is the way to do it.
See also:
How to handle a ctrl-break signal in a command line interface
Console Event Handling
On Linux and other Unix systems, the console runs as a separate process. As you close the shell, it sends the SIGHUP signal to the currently active process or processes that are not executed in the background. If the programmer does not handle it, the process simply terminates. The same signal is sent if you close the SSH session with a terminal and an active process.
SIGBREAK is raised on Windows.
I am using SDL for an OpenGL application, running on Linux. My problem is that SDL is catching SIGINT and ignoring it. This is a pain because I am developing through a screen session, and I can't kill the running program with CTRL-C (the program the computer is running on is connected to a projector and has no input devices).
Is there a flag or something I can pass to SDL so that it does not capture SIGINT? I really just want the program to stop when it receives the signal (ie when I press ctrl-c).
Ctrl-C at the console generates an SDL_QUIT event. You can watch for this event using SDL_PollEvent or SDL_WaitEvent, and exit (cleanly) when it is detected.
Note that other actions can generate an SDL_QUIT event (e.g. attempting to close your main window via the window manager).
I have found an answer:
The SDL_INIT_NOPARACHUTE flag will capture fatal signals so that SDL can clean up after itself. It works for things like SIGSEGV, but apparently SIGINT is not fatal enough.
My solution is to reset the signal handler to SIGINT after SDL has been initialised:
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE);
signal(SIGINT, SIG_DFL);
Thanks Cache for you input, it put me on the right track.
Michael
In SDL_quit.c, there's a check for hints to determine whether the signal handlers should not be used in SDL_QuitInit(). Not sure if this existed in older versions when the original question was asked, but may be handy for those coming here fresh.
Just tested on my Windows application, I can now receive all signals properly again, using:
SDL_SetHint(SDL_HINT_NO_SIGNAL_HANDLERS, "1");
SDL_Init(...);
Passing the SDL_INIT_NOPARACHUTE initialisation flag to SDL_Init "Prevents SDL from catching fatal signals".
See: http://www.libsdl.org/cgi/docwiki.cgi/SDL_Init
If you're not actually using an event loop for some reason, you can use SDL_QuitRequested in your "poll stuff" loop.