Subclassing QThread and signals/slots?
-
Hi,
For years I've been using QThread in my apps in both ways mentioned in the documentation: subclassing and as worker-object with moveToThread().
Today I discovered in the QThread documentation for the subclassing method, "There will not be any event loop running in the thread unless you call exec()."
When subclassing, I haven't been calling exec() but I often have signals and slots and they work just fine (as far as I know). With one caveat that some of my customers have reported rare glitching - that I've never been able to replicate or explain - in one of my realtime audio apps that does have signals and slots passing data from a subclassed QThread audio worker thread to the GUI.
The QThread documentation then goes on to say, "It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread can calls run(). This means that all QThread's queued slots and invoked methods will execute in the old thread. Thus a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly in into a subclassed QThread."
The obvious questions to me are:
a) why are signals and slots even allowed in a subclassed thread - maybe there should be a compile error or warning? - and
b) why aren't my realtime audio apps suffering more poorly or even crashing?I now have at least a few day's work ahead changing the subclasses to worker-object.
Thanks,
Michael -
Hi,
For years I've been using QThread in my apps in both ways mentioned in the documentation: subclassing and as worker-object with moveToThread().
Today I discovered in the QThread documentation for the subclassing method, "There will not be any event loop running in the thread unless you call exec()."
When subclassing, I haven't been calling exec() but I often have signals and slots and they work just fine (as far as I know). With one caveat that some of my customers have reported rare glitching - that I've never been able to replicate or explain - in one of my realtime audio apps that does have signals and slots passing data from a subclassed QThread audio worker thread to the GUI.
The QThread documentation then goes on to say, "It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread can calls run(). This means that all QThread's queued slots and invoked methods will execute in the old thread. Thus a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly in into a subclassed QThread."
The obvious questions to me are:
a) why are signals and slots even allowed in a subclassed thread - maybe there should be a compile error or warning? - and
b) why aren't my realtime audio apps suffering more poorly or even crashing?I now have at least a few day's work ahead changing the subclasses to worker-object.
Thanks,
Michael@mjsmithers said in Subclassing QThread and signals/slots?:
a) why are signals and slots even allowed in a subclassed thread - maybe there should be a compile error or warning? - and
I don't see a reason why QThread should not have signals and slots. Even when you derive from it, the object should be able to emit signals. Having a slot is also fine because you can also move the derived QThread into the newly created thread.
b) why aren't my realtime audio apps suffering more poorly or even crashing?
I don't understand this - if your code is correct why should it crash?
-
Thanks. Yep, I'm fine with QThread allowing signals and slots, but I think a compile warning is warranted when subclassing and the subclass has signals and slots.
I fully realise that I'm at fault here for not thoroughly reading the documentation and understanding the implications.
Re point b), this is more an expression of frustration to myself. Why would there be problems? The subclassed thread is a worker thread that's processing audio passed to/from and audio soundcard callback. General practice is that nothing in the callback and in threads working for/with the callback should do anything that could cause system calls; like mutexes, heap allocation etc.. (Even the FIFO linking the audio callback and the worker thread is lock free and just uses atomic ints.) The problem for me is that the worker thread is sending/receiving signals that (according to the documentation) are running in the parent (GUI) thread and therefore risk stalling the worker thread and affecting the audio to/from the callback. This is what I think my customers have experienced, but I've never been able to replicate.
Best,
Michael -
Thanks. Yep, I'm fine with QThread allowing signals and slots, but I think a compile warning is warranted when subclassing and the subclass has signals and slots.
I fully realise that I'm at fault here for not thoroughly reading the documentation and understanding the implications.
Re point b), this is more an expression of frustration to myself. Why would there be problems? The subclassed thread is a worker thread that's processing audio passed to/from and audio soundcard callback. General practice is that nothing in the callback and in threads working for/with the callback should do anything that could cause system calls; like mutexes, heap allocation etc.. (Even the FIFO linking the audio callback and the worker thread is lock free and just uses atomic ints.) The problem for me is that the worker thread is sending/receiving signals that (according to the documentation) are running in the parent (GUI) thread and therefore risk stalling the worker thread and affecting the audio to/from the callback. This is what I think my customers have experienced, but I've never been able to replicate.
Best,
Michael@mjsmithers said in Subclassing QThread and signals/slots?:
Thanks. Yep, I'm fine with QThread allowing signals and slots, but I think a compile warning is warranted when subclassing and the subclass has signals and slots.
What warning? Did you remember to put the required
Q_OBJECTmacro in? -
@mjsmithers said in Subclassing QThread and signals/slots?:
Thanks. Yep, I'm fine with QThread allowing signals and slots, but I think a compile warning is warranted when subclassing and the subclass has signals and slots.
What warning? Did you remember to put the required
Q_OBJECTmacro in? -
@JonB I'm suggesting Qt provide a warning when subclassing Qthread and signals and slots are present in the header file. (Yes, of course I have the Q_OBJECT macro, otherwise my project wouldn't compile and run.)
@mjsmithers
A warning for what? This has nothing to do withQThreadparticularly, anyQObject-derived class will have this issue.And Qt (Creator) is not a compiler, your compiler is external, so it could not "provide a warning".
