[Qt-interest] Threading and objects...

[K. Frank]

Hello Sean and Everyone -

On Fri, Nov 12, 2010 at 3:57 AM, Sean Harmer
<sean.harmer at maps-technology.com> wrote:
> Hi,
>
> 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();

> ...
>
> HTH,
>
> Sean

Thanks for your thoughts.


K. Frank