Console Application cannot stop properly a thread

[yeye_olive]

Not in the case of quitting the application.

OK. This design is a bit more general in that it lets the user decide what to do with the notification.

The Qt::QueuedConnection takes care of the thread crossing by sending the method invocation request as an event to the receiver object's thread event loop.

Yes, that is why I chose to rely on Qt's thread safe signal emission. That is not why the mutex is needed. The mutex is here because the receiver object might not exist any more when winHandler runs. After unregistering the handler, I cannot tell when winHandler will definitely never be run any more. The problem would be the same with a call to QMetaObject::invokeMethod() for QCoreApplication::quit(). I would have no guarantee that winHandler would not be run after the QCoreApplication object was deallocated (which I suppose could happen if the OS queued two invocations of winHandler, then one was performed, then the application started to quit and winHandler ran again).

[anda_skoa]

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,
_

[yeye_olive]

How likely is this winHandler being called after the program has stopped?

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.

[anda_skoa]

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.

So what makes the instance of the mutex safer than the instance of the application?

Cheers,
_

[wysota]

There is a simple workaround for this chicken and egg problem - remove the handler before the application object is destroyed.

[yeye_olive]

So what makes the instance of the mutex safer than the instance of the application?

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.

There is a simple workaround for this chicken and egg problem - remove the handler before the application object is destroyed.

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.

[wysota]

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).

[yeye_olive]

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).

Indeed, there is a solution for Unix signals. By contrast, Windows spawns a thread to execute the handler everytime the signal is received; sadly, handler unregistration offers no way to synchronize with any thread currently executing the handler being unregistered.

[wysota]

Indeed, there is a solution for Unix signals. By contrast, Windows spawns a thread to execute the handler everytime the signal is received; sadly, handler unregistration offers no way to synchronize with any thread currently executing the handler being unregistered.

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?

[yeye_olive]

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?

(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.