Emitting Signal from Slot problem in multithreaded environment
-
Thanks, that definitely solved the problem with the example.
Is there a way to have queued connections work within another thread when the thread is not within a QThread, ie. when exec() is not available? In my actual code the thread is created using AfxBeginThread().
-
you will need a Qt event loop to process Qt signals with queued connections. given you have to mix MFC and Qt I'd use a signal system that is independent from both while still being thread safe to make them interact. The first thing that comes in mind is, of course, Boost.Signals2 http://www.boost.org/doc/libs/1_61_0/doc/html/signals2.html
-
Thanks, that definitely solved the problem with the example.
Is there a way to have queued connections work within another thread when the thread is not within a QThread, ie. when exec() is not available? In my actual code the thread is created using AfxBeginThread().
IIRC QThread::exec() starts a event loop (QEventLoop). Signals coming from a different thread a placed as events in the event loop of the receiving thread. I do not think it's possible to have Qt event handling without this event loop. Maybe you can use your own QEventLoop object AfxBeginThread thread?
-
IIRC QThread::exec() starts a event loop (QEventLoop). Signals coming from a different thread a placed as events in the event loop of the receiving thread. I do not think it's possible to have Qt event handling without this event loop. Maybe you can use your own QEventLoop object AfxBeginThread thread?
Thanks. That seemed to solve the problem. Creating a QEventLoop object inside the thread and calling exec() on it allowed all events to be processed correctly.
Thanks for all the help.
edit: @VRonin Using an independent signalling system such as Boost would be a good idea too, which I will consider. Thanks.
-
Thanks. That seemed to solve the problem. Creating a QEventLoop object inside the thread and calling exec() on it allowed all events to be processed correctly.
Thanks for all the help.
edit: @VRonin Using an independent signalling system such as Boost would be a good idea too, which I will consider. Thanks.
@Floofy.KH
@t3685 beat me to it, this is what I would have suggested.QThread::execcallsQEventLoop::execanyway (same withQCoreApplication::exec), so you can substitute it with a call to the local event loop most of the time. I would, however, also suggest you try and migrate the WinAPI portions of your code to Qt (i.e. not creating the threads withAfxBeginThread), which incidentally will also make your code portable.Kind regards.
Read and abide by the Qt Code of Conduct
-
@Floofy.KH
@t3685 beat me to it, this is what I would have suggested.QThread::execcallsQEventLoop::execanyway (same withQCoreApplication::exec), so you can substitute it with a call to the local event loop most of the time. I would, however, also suggest you try and migrate the WinAPI portions of your code to Qt (i.e. not creating the threads withAfxBeginThread), which incidentally will also make your code portable.Kind regards.
@kshegunov @t3685 Won't calling QEventLoop::exec from the MFC thread block it until exec returns?
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@kshegunov @t3685 Won't calling QEventLoop::exec from the MFC thread block it until exec returns?
@VRonin
It will, but I assume that's one of the reasons he's starting the thread to begin with.Read and abide by the Qt Code of Conduct
-
@VRonin
It will, but I assume that's one of the reasons he's starting the thread to begin with.@kshegunov Let me rephrase: aren't we just flipping the pancake here? if you don't call QEventLoop::exec() you won't be able to process Qt signals, but if you call it then MFC will not be able to process its events any more.
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@kshegunov Let me rephrase: aren't we just flipping the pancake here? if you don't call QEventLoop::exec() you won't be able to process Qt signals, but if you call it then MFC will not be able to process its events any more.
@VRonin said in Emitting Signal from Slot problem in multithreaded environment:
Let me rephrase: aren't we just flipping the pancake here?
I honestly don't know, we may be. The thing is I have only partial information on what are the requirements and reasoning behind them, so I can at most guess about the initial intent.
If you don't call QEventLoop::exec() you won't be able to process Qt signals, but if you call it then MFC will not be able to process its events any more.
I have forgotten most of the MFC-related API, but what events does it needs processing (in a thread)? I understand that for the application there's integration with the system event loop (both for Qt and for MFC), but I believe there's no system event loop for threads. On a related note, the event loop is needed only for queued connections, so he can use direct connections (with proper locking) without it, thus the
boost's signal support sadly doesn't bring anything new here.Read and abide by the Qt Code of Conduct
-
@VRonin said in Emitting Signal from Slot problem in multithreaded environment:
Let me rephrase: aren't we just flipping the pancake here?
I honestly don't know, we may be. The thing is I have only partial information on what are the requirements and reasoning behind them, so I can at most guess about the initial intent.
If you don't call QEventLoop::exec() you won't be able to process Qt signals, but if you call it then MFC will not be able to process its events any more.
I have forgotten most of the MFC-related API, but what events does it needs processing (in a thread)? I understand that for the application there's integration with the system event loop (both for Qt and for MFC), but I believe there's no system event loop for threads. On a related note, the event loop is needed only for queued connections, so he can use direct connections (with proper locking) without it, thus the
boost's signal support sadly doesn't bring anything new here.@kshegunov True, we don't have enough info. but MFC allows to run a new GUI thread: https://msdn.microsoft.com/en-us/library/b807sta6.aspx and that would not work if we call QEventLoop::exec().
so he can use direct connections (with proper locking)
I thought Boost.Signal2 was exactly that. mutex-ed direct connection signals
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@kshegunov True, we don't have enough info. but MFC allows to run a new GUI thread: https://msdn.microsoft.com/en-us/library/b807sta6.aspx and that would not work if we call QEventLoop::exec().
so he can use direct connections (with proper locking)
I thought Boost.Signal2 was exactly that. mutex-ed direct connection signals
@VRonin said in Emitting Signal from Slot problem in multithreaded environment:
and that would not work if we call QEventLoop::exec()
You won't get any argument from me on that one.
I thought Boost.Signal2 was exactly that. mutex-ed direct connection signals
I didn't know it existed, but yes, I suppose that's a possible solution. The only problem I envision with that approach, taking in mind that new piece of information, is that mixing Qt's signal slot system and an external one is (sometimes) a big pain in the ass ...
