[Qt-interest] Queued/DirectConnections for signals across threads

[BRM]

----- Original Message ----

From: Thiago Macieira <thiago at kde.org>
> Em Segunda-feira 14. Dezembro 2009, às 06.27.49, BRM escreveu:
> > class ObjectA : public QThread()
> > {
> > ..
> > ObjectA();
> > ~ObjectA();
> > void run();
> > protected slots:
> > void readFile();
> > ...
> > public slots:
> > void pauseRead(bool _pause);
> > ...
> > protected:
> > bool pauseReading;
> > };
> > 
> > 
> > void ObjectA::run()
> >     {
> >     QTimer::singleShot(10,this,SLOT(readFile()));
> >     exec();
> >     }
> > void ObjectA::readFile()
> >     {
> >     if (pauseReading == false)
> >         {
> >         // do your normal read stuff here
> >         }
> >     ...
> >     QTimer::singleShot(1,this,SLOT(readFile()));
> >     }
> > void ObjectA::pauseRead(bool _pause)
> >     {
> >     pauseReading = _pause;
> >     }
> > That should effectively do it; though you may need another object layer in
> >  the thread. I usually do that - having a QThread derived class that
> >  allocates a class that has all the work the thread is suppose to do, and
> >  then the QThread derived class is just a signal relay class that ensures
> >  the thread boundary is properly crossed.
> The usual warning about using QThread as the target for signal connections: 
> the slot is run in the main thread.
> The code above does use the auxiliary thread's event loop to wait for 10 
> milliseconds. Then it posts and event back to the main thread so that it (the 
> main thread) can call readFile().

Thus my statement about the extra object layer. The above was just to show the principle.

Ben