[Qt-interest] Threading and objects...

[Sean Harmer]

Hi,

On Friday 12 November 2010 13:46:22 K. Frank wrote:
> Hello Sean and Everyone -
> <sean.harmer at maps-technology.com> wrote:
> > On Thursday 11 November 2010 16:54:36 BRM wrote:
> >> I have been doing quite a bit of multithreading with Qt for a while; and
> >> recently read (on the Qt blogs, a couple months back[1]) about the
> >> "right way" to use QThread;
> > 
> > <snip>
> > 
> >> In my new approach, I'm trying to keep the same basic architecture, at
> >> least for now while I get to figure out the new approach -
> > 
> > <snip>
> > 
> > The approach that I normally take to this is to have a trivial subclass
> > of QThread that contains as members pointers to the one or more objects
> > that actually do the work in the context of the thread.
> > 
> > There is no need to have forwarding signals from the thread class itself.
> > Just expose the pointers to the worker objects, then you can simply use
> > them to make connections between the worker objects and whatever else
> > you have.
> > 
> > I normally create the worker objects inside the run() function of my
> > QThread subclass. The only thing to be careful of is to make sure that
> > your object is created before you try to use it in a connect() call. To
> > help with this I usually use a simple waitForStart() function (see
> > attached example). The alternative is to use moveToThread() but I find
> > this less maintainable.
> 
> On the  other hand, why not...?
> 
> First, what your doing seems to make good sense, and is nice and
> organized -- my question is about mulling over alternatives, and is
> not to suggest that your choice isn't as good or better.
> 
> So, why not subclass QThread to give it the functionality of its primary
> worker object, and moveToThread it to itself when it's instantiated,
> presumably in its constructor, or something?
> 
>    auto workerThread = new DoSomeWorkThreadSubcalss;
>    workerThread->start();

I guess it's just how I visualise the concepts encapsulated by QThread. I tend 
to think of QThread as a class to manage a thread rather than as a way of 
doing work within that thread.

The main advantage to me is that it keeps the conceptual model clearer in my 
(little) brain ;-). 

It also allows me to reuse the worker objects in the main thread or in some 
other worker thread that also uses additional objects without being tied into 
a specific QThread subclass and then havong to refactor things later. 

For example, I often develop and unit test worker objects in a single threaded 
environment and then in my main application just instantiate them within the 
QThread::run() function instead of the main thread. This way QThread::run() 
can be thought of just like main() in the main thread. In fact it will use 
exactly the same pattern:

* create objects
* maybe enter event loop
* cleanup

Coupling the worker object logic into the QThread subclass is perfectly 
reasonable of course but if designing a library then I like to be able to 
reuse things in a differently threaded context.

At the end of the day it is down to personal choice and how you intend to use 
the worker logic and envisage that someone may want to use that logic 
differently in the future.

ATB,

Sean