Is the event system running in multithreaded mode

SuperJarvisCN

Can the default event queue be automatically distributed to different threads?

SGaist

Hi,

An event queue runs on one thread. What do you have in mind ?

Kent-Dorfman

The proof in what @SGaist mentioned is as follows: try a blocking operation any QWidget object. If there was a separate event queue then only that particular QWidget would block...what happens though is that the whole event system blocks.

SuperJarvisCN

@SGaist
As far as I know, the paintEvent is executed on another thread, right?
Are all other events executed in one thread?
Can signals be automatically sent and received across threads?
Is there automatic multithreading mode?
When constructing a widget, automatically place the widget in the thread pool and run it in parallel.

JKSH

@SuperJarvisCN said in Is the event system running in multithreaded mode:

As far as I know, the paintEvent is executed on another thread, right?

No. Paint events are processed by the GUI thread (which is usually the main thread)

Are all other events executed in one thread?

Yes, there is only 1 thread by default.

Can signals be automatically sent and received across threads?

Yes. See https://doc.qt.io/qt-5/qobject.html#thread-affinity for more details.

Is there automatic multithreading mode?

No. You must start a new thread if you want threads.

When constructing a widget, automatically place the widget in the thread pool and run it in parallel.

You cannot put widgets in different threads. All widgets must live in the GUI thread.

SimonSchroeder

I'd like to add to what @JKSH already said to, maybe, make it a little clearer.

By default you only have one event loop. You can start specific threads with their own event loop (just create a QThread object and call run() on it). However, multiple event loops cannot share the work automatically. Each event loop only processes the events of their own thread (and so every thread can only have one active event loop). Qt handles automatically which thread will receive the event. This is done based on which thread the receiver object is living in. In general, you can call moveToThread(...) on any object deriving from QObject. But, you are not allowed to do that for your widgets. Anything GUI related has to be handled by the event loop of the GUI thread (which usually is the main thread). This is (or at least was, I am not sure) a restriction of the underlying operating system.

For many applications you don't really have to be concerned about were to execute your slots. For most applications it is sufficient to just execute heavy workloads in separate threads. This does not necessarily require an event loop in the worker thread. For sufficiently large workloads you can just create a new thread for the work to be done. It gets a little bit complicated if you want to include a progress display. Since we ran into this problem over and over again, we developed a small wrapper library for Qt where you can easily put workloads into a separate thread (https://github.com/SimonSchroeder/QtThreadHelper).

Only in few applications will you actually have a problem that drawing is too slow. If you implement your own paint method you can actually draw to a pixmap in a separate thread and let the paint method just show that pixmap on the screen. There will be very few cases where this approach is actually necessary.

SGaist

@SimonSchroeder said in Is the event system running in multithreaded mode:

If you implement your own paint method you can actually draw to a pixmap in a separate thread and let the paint method just show that pixmap on the screen

One small precision: QImage not QPixmap for secondary thread painting. The later is tied to the windowing system and follows the same rules as widgets.

SimonSchroeder

@SGaist said in Is the event system running in multithreaded mode:

One small precision: QImage not QPixmap for secondary thread painting. The later is tied to the windowing system and follows the same rules as widgets.

I guess we did it wrong then. Still works with QPixmap ;-)

SGaist

@SimonSchroeder said in Is the event system running in multithreaded mode:

@SGaist said in Is the event system running in multithreaded mode:

One small precision: QImage not QPixmap for secondary thread painting. The later is tied to the windowing system and follows the same rules as widgets.

I guess we did it wrong then. Still works with QPixmap ;-)

Now you know that it's time bomb waiting to bug the hell out of you ;-)