Boost Thread Qt Application

How-to launch Qt Application in a non-main thread

In this article I’ll show how to manage running QApplication in a non-main thread. My need is to create an external shared library,
that can offer a GUI interface when requested.

Anyway, I don’t have control on the external process that loads my library, and I have to face the following two requirements:

a) loading of my library is performed in a thread;
b) calling of the public method that shows GUI interfaces happens in a different thread.

My solution requires the usage of boost::thread class (even if you can use any other thread-management technology, i.e. POSIX thread API,
but not QThread class). Boost Thread lets me preserve “code once, run everywhere” requirement.

Some basic ideas were taken from VLC source code.

Here’s just a sample of my solution, that has been extracted from my top-secret code :)

application.hpp file:

application.cpp file:

My goal is to create my widget in the same thread of QApplication, as Qt requires, wait until the widget is shown, and let my widget run in the QApplication event loop context.

When one of my shared library public methods is called for the first time,
I create an instance of the runnable ThreadedApplication class, and I fire it using boost::thread:

So, let’s call “Thread A” the thread that executes the public method of my library, that performs the three lines above.
A new thread is created (the “boost” one), called “Thread B”, that creates an instance of QApplication, my DialogProvider, and executes
event loop of QApplication, everything in the same context.
“Thread A” is blocked until I’m sure that my application is started, then returns.

Some time later, a new thread, called “Thread C”, wants to call a different public method that shows my widget.
I just need to call

Of course, the two parameters are specified as example. “Thread C” posts a custom event (that carries on all information I need to create my widget)
to QApplication event loop, that forwards it to my DialogProvider customEvent method.
In that method (I’m in QApplication context, i.e. “Thread B”), I can create my widget and show it!! In the end, I just signal (using a QWaitCondition)
that my widget is shown, so “Thread C” can return.

The final result is that all my Qt classes have been created in the QApplication thread context, just as a normal Qt application. Qt world is unaware of what
has happened, and it never complains about anything.

Just a warning about widgets creation and destruction in customEvent method. NEVER delete them there!!! QDialog based widgets can let you do wrong, cause usually you destroy the dialog just after executing them. Please use WA_DeleteOnClose attribute, as in my example, or defer their deletion using deleteLater method.

Comments on how to improve such solution are welcome!!!

Antonio Di Monaco

Categories:

• HowTo