Well, in the case of QCoreApplication::instance() it is valid pointer until the application has be destroyed.
Which happens after the return of main().
How likely is this winHandler being called after the program has stopped?
Cheers,
_
Well, in the case of QCoreApplication::instance() it is valid pointer until the application has be destroyed.
Which happens after the return of main().
How likely is this winHandler being called after the program has stopped?
Cheers,
_
Granted, it is highly unlikely that winHandler executes sometime between the point where the QCoreApplication instance starts being destroyed and the point the program terminates, but, as far as I can tell by reading Microsoft's documentation, nothing guarantees that it cannot happen. In fact, the documentation does not say anything about what happens after a handler has been unregistered.
Better safe than sorry.
There is a simple workaround for this chicken and egg problem - remove the handler before the application object is destroyed.
Nothing, really. The mutex probably stays a little while longer since it is a global variable while the QCoreApplication is usually allocated on the stack in main(), but this does not eliminate the problem. I suppose there is no way around it, since there is no way to synchronize with the thread executing the handler, if any.
How does it solve anything? Unfortunately, removing the handler does not guarantee that it will not be subsequently run, hence the need for a check in the handler.
Last edited by yeye_olive; 23rd December 2014 at 19:57.
I don't know about Windows but in Unix there is no magic extra thread executing the handler, you can even designate a particular thread of the application to be executing a particular handler. Therefore the execution is synchronous with the flow of the program for one of the application threads therefore if no threads apart the main one outlive the application object, removing the handler before the application is destroyed makes sure the handler will not be called at any later point in time (as in after the application object dies).
It is enough to check in the handier whether the application object is valid before proceeding. However I am quite surprised about what you say that an extra thread is spawned - by whom? Operating system does not spawn threads for processes. The code for this would have to be generated by the compiler. I just read the docs for this function and it says nothing about any extra threads being spawned. Where did you get this information from?
Last edited by wysota; 24th December 2014 at 20:01.
(Sorry for the late reply. I have been offline for about a week.) I got this information from the HandlerRoutine page of the documentation, which is linked from the page for SetConsoleCtrlHandler; it is most unfortunate that the information be scattered around like this. The exact wording is When the signal is received, the system creates a new thread in the process to execute the function. A bit further down, a remark acknowledges the need for synchronization with the other threads of the process.
Bookmarks