Console Application cannot stop properly a thread

[erakis]

I confirm that it is well working on Linux (Ubuntu) using CTRL+C but ONLY while lunching it from a shell.
Doing the same thing using the QtCreator debugger only throw an EXCEPTION and nothing happen except breaking on the a.exec() line. If we click on CONTINUE command of the debugger, the process simply continue without stopping... weird !

For Windows : I'll try the other stuff I mentioned in the previous post and I will come back here for conclusion.

[wysota]

I confirm that it is well working on Linux (Ubuntu) using CTRL+C but ONLY while lunching it from a shell.
Doing the same thing using the QtCreator debugger only throw an EXCEPTION and nothing happen except breaking on the a.exec() line. If we click on CONTINUE command of the debugger, the process simply continue without stopping... weird!

That is perfectly normal, the debugger is intercepting the signal. Run the application without a debugger and it will behave as expected.

[yeye_olive]

This might be coming a bit late, but I can confirm that SetConsoleCtrlHandler() definitely is the way to go. I have used it several times. I once wrote an OS-independent abstraction of a "termination handler" that would emit a Qt signal when receiving a termination request from the OS. The implementation for Windows console applications used SetConsoleCtrlHandler() and the design was roughly along these lines (but with some hiding of the internal structures):

class Handler : public QObject {
Q_OBJECT
signals:
	void terminated();
public:
	void emitTerminated() {
		emit terminated();
	}
};
 
QMutex mutex;
Handler *handler = NULL;
 
BOOL WINAPI winHandler(DWORD /*dwCtrlType*/) {
	QMutexLocker lock(&mutex);
	if (handler == NULL)
		return FALSE;
	handler->emitTerminated();
	return TRUE;
}
 
void registerHandler() {
	QMutexLocker lock(&mutex);
	assert(handler == NULL);
	handler = new Handler;
	SetConsoleCtrlHandler(winHandler, TRUE);
}
 
void unregisterHandler() {
	QMutexLocker lock(&mutex);
	handler->deleteLater();
	handler = NULL;
	SetConsoleCtrlHandler(winHandler, FALSE);
}

class Handler : public QObject {
Q_OBJECT
signals:
	void terminated();
public:
	void emitTerminated() {
		emit terminated();
	}
};

QMutex mutex;
Handler *handler = NULL;

BOOL WINAPI winHandler(DWORD /*dwCtrlType*/) {
	QMutexLocker lock(&mutex);
	if (handler == NULL)
		return FALSE;
	handler->emitTerminated();
	return TRUE;
}

void registerHandler() {
	QMutexLocker lock(&mutex);
	assert(handler == NULL);
	handler = new Handler;
	SetConsoleCtrlHandler(winHandler, TRUE);
}

void unregisterHandler() {
	QMutexLocker lock(&mutex);
	handler->deleteLater();
	handler = NULL;
	SetConsoleCtrlHandler(winHandler, FALSE);
}

To copy to clipboard, switch view to plain text mode 

You can then connect to the Handler::terminated() signal to be notified of the termination request.

[anda_skoa]

You can then connect to the Handler::terminated() signal to be notified of the termination request.

The QMetaObject::invokeMethod() should work in this case as well, i.e. inside winHandler(), without the need for global variables

Cheers,
_

[yeye_olive]

The QMetaObject::invokeMethod() should work in this case as well, i.e. inside winHandler(), without the need for global variables

I do not understand what you mean. The first argument of the QMetaObject::invokeMethod() call would still need to be stored in a global variable. In any case, there is no absolute need for the Handler class; one may invoke a slot on QCoreApplication::instance(), etc. Emitting a signal and letting the user decide who to connect it to just makes the design more modular (although evertything should be encapsulated and hidden behind a nicer interface). Besides, the mutex and the check (handler == NULL) are needed in case the user unregisters the handler when winHandler is about to run.

[anda_skoa]

The first argument of the QMetaObject::invokeMethod() call would still need to be stored in a global variable.

Not in the case of quitting the application.

Besides, the mutex and the check (handler == NULL) are needed in case the user unregisters the handler when winHandler is about to run.

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.

Cheers,
_

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