Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Have QCoreApplication::processEvents process only one type of event/message
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?
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?
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)
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
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 ?