QThread Blocking
-
I have a QMainWindow and want to use macros/scripts to automate things offered in the QMainWindow application. Among other things, this application uses a library that allows collecting data (in a thread) which also has a callback function when the data gathering is done. So it's something like this:
class MyWindow : public QMainWindow()
{
RunMacro(Macro macro);
static void CALLBACK MyCallback();
private slots:
OnGatherData();
}The macro could be something like this:
GatherData
WaitForDataGatheringDoneThe above are executed by RunMacro. What I did to not block the GUI is creating a threat, passing it a pointer to MyWindow and in that thread I call RunMacro. My expectation was, that because RunMacro is called by a different thread MyWindow would not block. However, it does seem to block because my callback function to indicate that the data gathering is done gets never called. If that is indeed the case, then how would I solve it that I still can get that callback and not block MyWindow?
-
@qt27
Hi,
This whole procedure sounds very suspicious and unnecessary, not to mention it probably is a disaster waiting to happen. What's the problem with connecting a few signals to some slots instead?The above are executed by RunMacro. What I did to not block the GUI is creating a threat, passing it a pointer to MyWindow and in that thread I call RunMacro.
You just basically described what you should not do. For one the GUI classes are not even reentrant, not to mention thread-safe and while one could probably make an argument for synchronizing a few own methods it is ultimately unneeded.
Kind regards.
-
@qt27, thanks for the feedback. So the only other option I see then is creating a thread that sends signals for each macro/script step to the MyWindow application. I was kind of hoping to avoid this as it means creating a lot of pretty much duplicate signals (one from the GUI which gets arguments from an input window and one for the script/macro which gets arguments from the script/macro).
-
So the only other option I see then is creating a thread that sends signals for each macro/script step to the MyWindow application.
Rather a worker object that runs inside a separate thread, but yes, that approach sounds much better to me.
I was kind of hoping to avoid this as it means creating a lot of pretty much duplicate signals (one from the GUI which gets arguments from an input window and one for the script/macro which gets arguments from the script/macro).
I wouldn't call two signals-slot connections "a lot" and you skip the whole manual thread synchronization fiasco ... I should think this is good, isn't it?
Kind regards.
