Does Qt creates any thread for handling Events?

[blue_sky]

There is some Concepts like Event Queue/Event loop for Queuing the Events and proceeding one after another.If there is an extra thread to respond OS events, no problem to make a Event Queue and dispatch one by one when main thread will finish one task(executing set of codes after an event).
But what’s the scenario if only one thread is present?
Please take a look at flow asked in a Question
http://stackoverflow.com/questions/16812602/qt-main-gui-and-other-thread-events-loops
—and help me.

[wysota]

Qt does not create any threads to handle events. Events have affinity with threads, not the other way round.

[blue_sky]

It means the Event Queue is accessible by both the thread and OS Event Dispatcher.Otherwise how an executing thread can add a message from OS,while it processing some other codes? Am I right?


Qt does not create any threads to handle events. Events have affinity with threads, not the other way round.

It means the Event Queue is accessible by both the thread and OS Event Dispatcher.Otherwise how an executing thread can add a message from OS,while it processing some other codes? Am I right?

[anda_skoa]

Not sure what you mean with "OS Event Dispatcher".

Each thread has a QEventDispatcher instance, each usually hooked into the OS to process system events such as timers and sockets.
The event dispatcher instance is where the thread "sleeps", i.e. waits for events.

Whether OS events can be added while the thread is processing depends on how the OS event API works.
If it is "pull" based, e.g. like Unix select(), then no. The thread will see the new event when it returns to the event dispatcher.

If it is callback based and the system has its own thread for doing those callbacks, then yes, that system thread might add events while another is being processed. No idea if the only non-Unix platform (Windows) does that.

Cheers,
_