Important: Please read the Qt Code of Conduct -

Have QCoreApplication::processEvents process only one type of event/message

  • Hello,

    I have an application that has a main thread (GUI thread) and a worker thread.
    Sometimes the worker thread posts a message via a Qt::BlockingQueuedConnection. This is most of the time directly handled inside of QApplication::exec by the GUI thread, but it happens sometimes that the GUI thread needs to execute the worker thread's posts manually. For that, I am (in specific parts of the GUI code) calling QCoreApplication::processEvents(). That works fine, but is not elegant. Is there a method that would allow to process only the post that came from my worker thread?


  • Qt Champions 2017

    atleast I don't see any thing to process only the events from specific thread. Once you post event, it will be in the receiving thread context to process it.

  • Thanks for the reply.
    But I still believe there must be a possibility. When you submit an argument to the processEvents function, you can already filter the messages somehow, e.g.:


    Or - is there the possibility to set-up a new message pipe, just for my own specific messages?

  • Hello again,
    another idea that came to mind:

    is there the possibility to post a signal/event so that it will be placed at first position in the event loop? (first position --> handled first)

  • Lifetime Qt Champion


    No, this is not possible. The only way I see (never done it though) would be to try to implement your own QAbstractEventDispatcher.

    What makes that signal/message so urgent ?

  • Thanks for your reply. Here is my problem, simplified:

    I have a GUI thread in charge if the GUI and rendering of a complex scene. Then I have a simulation thread that generates new scene content. The simulation thread can invoke GUI dialogs such as message boxes, file dialogs, etc. This happens via signals/slots, and the simulation thread will wait until the GUI has executed the posted command (i.e. Qt::BlockingQueuedConnection).

    Above works fine, but I also need a synchronization between the GUI thread and the simulation thread:

    • When the GUI reads from the resources, the simulation thread cannot write to the resources
    • When the GUI writes to the resources, the simulation thread has to be halted
    • When the simulation thread writes to the resources, the GUI thread cannot read nor write to the resources

    Above synchronization works fine using 2 mutexes that lock resources:

    • guiReadMutex: when locked by the simulation thread, the GUI cannot read resources
    • guiWriteMutex: when locked by the simulation thread, the GUI cannot write resources

    My problems come from the fact that if the simulation thread invokes a file dialog (for instance) while modifying the resources, the GUI event loop has to run (otherwise the file dialog won't display). But since the simulation thread is in a write mode, the GUI is not allowed to read or write the resources. Which means that most messages from the message loop will be discarded (at each GUI entry point I check if resources can be locked for read or write. If they cannot, the routine is not executed (e.g. a mouse click ignored)). MY file dialog gets displayed correctly by the GUI, but most other messages have been lost.

    So ideally, when my simulation thread invokes the file dialog, I just want the GUI thread to execute that posted command, but leave the other messages in place. The other messages can then be executed at a later stage, when the simulation thread is not modifying the resources anymore.

    Above description is simplified, but correspond pretty much to what is going on.

    Thanks for any advice

  • Lifetime Qt Champion

    Can you define what your "resources" are ?

    It seems that you are trying to give to much power to your simulation thread. It should only do what he is designed for: simulate. If it needs something that involves a GUI it should be handled outside of it. IMHO your simulation should not use GUI at all.

    Rather than two mutexes maybe a QReadWriteLock ?

Log in to reply