I have an application for which a cleanup code should be run regardless of the way how the process ended. For example, if the program is being closed by the OS due to a restart, the cleanup code should be executed. Or if CTRL+C is pressed, the cleanup code should be executed.
I've found the QCoreApplication::aboutToQuit signal.
The docs for the signal state:
This signal is emitted when the application is about to quit the main event loop, e.g. when the event loop level drops to zero. This
may happen either after a call to quit() from inside the application
or when the users shuts down the entire desktop session.
The signal is particularly useful if your application has to do some
last-second cleanup. Note that no user interaction is possible in this
state.
However after testing, I've noticed that the signal isn't emitted when CTRL-C is pressed. It also isn't emitted when terminated by kill.
On what 'exit' events is the signal emitted?
My current opinion is that QCoreApplication::aboutToQuit is useless for handling outside signals and that it is used for 'exiting from inside an app' kind of events (a user clicks the X button to close the window), but won't help you if you want to make sure a certain event is executed even on a segmentation fault or the process being externally killed.
You can do it like this (had the same problem a while back and found it to work quite well):
http://www.thegeekstuff.com/2012/03/catch-signals-sample-c-code/
Good sample code + all system signals:
http://www.yolinux.com/TUTORIALS/C++Signals.html
Related
I've been learning about the event loop and asynchronous code execution in Dart. Here is how I understand it works:
Dart runs the synchronous code in main first.
Any completed futures are put on the event queue and get run in FIFO order.
Any microtask events get handled before the next event in the event queue.
The part I'm missing is what about an uncompleted future? What if you have something like this:
final myFuture = Future<int>.delayed(
Duration(seconds: 1),
() => 42,
);
In that one second delay, say all the synchronous code, microtasks, and event queue tasks have completed. How does Dart know it shouldn't terminate the program? Is there a little holder somewhere for uncompleted futures?
I don't know if my title accurately reflects what I'm asking. Feel free it edit it.
The life-time of a Dart program depends on where it runs.
Code running in a browser doesn't stop unless the page goes away. Web pages won't end like a script or application does.
So, what you are likely really asking is when a program run on the Dart VM stops. The short answer is: When there is nothing more to do (in the main isolate).
The program ends when the main isolate is done. That's the first isolate to run. If you start new isolates, they won't keep the program alive by themselves, so make sure to keep the main isolate alive until your program is done.
An isolate is done when there is nothing more to do, and there is no good way to receive instructions to do something more.
That means:
There is no code running.
The event and microtask queues are empty.
There are no scheduled timers or outstanding I/O operations (you can think of these as being kept in separate internal work queues, and when they have a result ready, they trigger events in the main event queue. These queues also need to be empty for the program to be done).
There are no open receive ports (ReceivePort, RawReceivePort).
That means that there is nothing to do, and no open communication channels to receive messages on.
The traditional way to keep an isolate alive, perhaps because the real computation is being done in a different isolate, is to create a ReceivePort, and then close it when everything else is done (which you'd probably notify them about by sending an event to that receive-port).
I'm developing an application that uses a device (microprocessor) connected to the pc via USB. I'm using a library with some specific functions for this microprocessor.
At the beginning of the application the user is always required to "login" into the device using a password. What this really do is to execute some initialization functions in the microprocessor, namely:
//microprocessor initialization functions
open();
device_session = s; // a structure
error=login(&s,password); //if password is ok opens a session
start();
When the user closes the application, I need to also close the device, executing:
//microprocessor closing functions
finish();
logout(&s); // it requires the session structure to close
close();
I do this in the destructor of my application.
The problem is, if my application crashes, the destructor is not executed and the neither are the closing functions. Therefore, the next time I launch the application, the initialization functions fail, as there is another session opened and I can not close it (because logout requires s). The only way to make it work again is to reconnect the device to the PC (hardware reset).
So my question is if it is possible to execute the closing functions even when my application crashes, no matter the origin of the error.
I'm trying Overriding QApplication::notify() as described here. Is this the correct approach?
Qt/C++ Error handling
Another approach I was considering is to have two applications, A and B.
A handles the microprocessor initialization and passes the session object to B.
B does everything else except closing the microprocessor connection.
When B is closed or crashes, A simply executes the closing functions. Could this work?
I apologize if the question seems stupid, but I don't have a lot of experience on developing applications. I tried to search for an answer before posting but I'm not sure what approach to follow, so I don't know what should I be searching to begin with.
Thanks a lot.
Say that you are designing a system with two subsystems: one is a state machine A and the other is a functional subsystem B. Subsystem B has methods like doAsync(), that perform some operation and later return a completion or error event back to system A.
Now subsystem A can receive events from other external system, like ModeChange which results in changing to the proper state.
Here is the problem. Say that subsystem A is in state AA that invoked the function doAsync() and is waiting for the completion event. Yet, before the completion event is received, I get a ModeChange event that now pushes subsystem A to state AB. However, the completion event for doAsync() is now received on state AB instead of AA and thus captured as an unexpected event.
What would be the best way to solve this problem?
Here are some possible solutions and my thoughts:
Implement cancel operation for every async operation in system B.
I would prefer not to do this since it add a lot more work. It would increase the complexity of system B.
Ignore the unexpected Events.
I don’t like this solution because it would hide other problems.
Could you tell me how can I determine between QMainWindow close event initiated by user and abonormal termination by SIG_KILL in Linux or TerminateProcess() in Windows?
That's because the difference in urgency exists.
I can refuse closing by user or user can think as long as required.
But I have to save intermediate results and current state as soon as possible when aborting or till the user will do next fatal abort try.
I can try to figure out analysing the mouse position on closeEvent(). But it depends on the taskbar look. I can set the app to non-minimized state and wait the next user actions. But that's not a good behaviour in the abort case. User can try the next fatal abort actions or the time for save would lost.
Best regards, Gennady
If you application receives a SIGKILL, it will not have any time to do anything. It is terminated on the spot. You can't catch or block that signal. So you can't "differentiate" a SIGKILL from normal application shutdown: you will not know when you have been forcefully killed. (Same thing for TerminateProcess().)
If you need to do something during normal application shutdown, you should connect your cleanup routine to the QCoreApplication::aboutToQuit() signal. Check the docs, that is exactly what it is designed for.
Is there a way to detect when a windows process is waiting for user input.
For instance, when you click on a particular program it loads, in this case the program's process is probably in loading state rite?
what happens when the program is fully loaded and is waiting for user input to procedure to next step. Is there a way to detect this?
Cheers
Call WaitForInputIdle with a handle to a process. it will suspend execution until the program completes its initialization and is waiting for user input with no input pending.