To SubClass or not to subclass? this is the question...
-
I was just wondering if its still a bad idea or lets say considered the wrong way to deal with threads if you subclass QThread I know in the 4.x versions any code i did with sub-classing of threads causes so much complaints that its the wrong way with other developers is this still the case with Qt5 I just feel that it is a QObject I mean there are signals going on right?
what I wonder about is if it works with no performance hit whats the fuss about!
and with regards to variables accessed from two different threads I can always lock and unlock threads so again I don't see why its wrong! -
Hi,
Both approaches are now described in the latest documentation with pros and cons. So the only good answer is: it depends on your use case. However most of the times you don't need to subclass.
The fuss is generally with thread affinity and where the slot will get executed (in the context of the thread managed by QThread or in the main thread ?) which are things that might be a bit convoluted when not knowing how direct/queued connections works and when and why they are chosen.
-
So what type of scenario would require that I don't go the subclass approach im sorry for asking this but its just one of the very few subjects with QT that im really confused with!
-
It all depends on your way of implementation. If you take care of where objects are created and wherer their slots are related to, you can subclass. I like that aproach more.
What I do is create a QThread subclass, give it some slots, and forward them to an inner object, created in the run method. This is save.
Or if you just use it as worker thraed without signal/slot (which is possible!), you subclass.
Thats just my 2 cents on this.
-
[quote author="echostorm" date="1413812237"]So what type of scenario would require that I don't go the subclass approach im sorry for asking this but its just one of the very few subjects with QT that im really confused with![/quote]
Usually, if you find yourself adding signals & slots to your subclassed QThread class, you should know that you are threading on thin ice and really need understand what you are doing.
My rule of thumb: use a vanilla QThread with a worker object unless you:
- are only doing some simple processing in your run() reimplementation that does not require signals and slots; or
- know what you are are doing and really understand signals, slots, objects, and threading in their interactions.
-
thanks for both of your inputs im just going to conclude that its not wrong to subclass hence im forwarding this post to my colleague developers and yes I think ill stick to subclassing cause its just much better for me since im used to that approach.
Again Thanks very much!
-
Thanks Andre I think what im doing is simple enough and basic lock unlock thread is all I require to make sure things run smoothly...
-
You probably already know it but avoid terminating your QThreads, a loop breaking variable is way nicer ;)
