[Qt-interest] QThread event loop running in main thread?

[Mihail Naydenov]

----- Original Message ----
> From: Thiago Macieira <thiago at kde.org>
> To: qt-interest at qt.nokia.com
> Sent: Tue, December 28, 2010 9:56:21 PM
> Subject: Re: [Qt-interest] QThread event loop running in main thread?
> 
> On Tuesday, 28 de December de 2010 07:27:14 Mihail Naydenov wrote:
> > Well,  the point I argue about is, that taking the Forbidden Step - in your 
> >  example myThreadWorker : public QThread
> > and get rid of workerThread  field is actually worth it - no need for stubs
> > to  control the  thread, access to sleep(), instantiate and mange two
> > instead of three  QObjects.
> 
> No, that's not the forbidden step.
> 
> Deriving from QThread  is completely legal and ok. Don't go talking about how 
> that is  wrong.
> 
> The documentation is still correct, even if incomplete. You don't  need to 
> derive from QThread in order to use it. But you can.

My reply you quote there is out of context, I am not propagating that 
subclassing qthread is wrong in general (reimpl run()).
(If you read my first post, I called it "the old way")

> 
> What is  *forbidden* is moveToThread(this). And because of that, more often 
> than not,  using slots in a class derived from QThread is often *wrong*.
> 
> Wrong  because it doesn't do what you think it does. Since the QThread object 
> was  created, obviously, in another thread, that's the thread to which events 
> will be posted. So that's the thread where slots will be called in, due to 
> queued connections.
> 
> So this code in the run()  function:
> 
>     QTimer::singleShot(0, this,  SLOT(someSlot()));
>     exec();
> 
> will probably not do  what you think it does! The slot "someSlot" will be 
> called in the original  thread, not in the thread that this QThread object 
> started.

Am aware of all that, as said, the reply you replay to is out of context.

> 
> Using  signals in a class derived from QThread isn't wrong. It's just a concept 
>
> violation. A signal called "workDone" means the job is done, not that the 
> thread is done. Otherwise, you could just use the "finished"  signal.

I agree with "concept  violation", still, if you know what are you doing, 
moveToThread(this) gives you 

the simples possible framework. That was the argument all about.

> 
> -- 
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Senior Product Manager - Nokia, Qt  Development Frameworks
>       PGP/GPG: 0x6EF45358;  fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5  F005 6EF4 5358
>