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?Thanks
-
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.:@processEvents(QEventLoop::ExcludeUserInputEvents);@
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)
-
Hi,
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 ?
