[Qt-interest] QThread event loop running in main thread?
Mihail Naydenov
mlists at ymail.com
Tue Dec 28 16:27:14 CET 2010
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.
Yes, it is the wrong way and the wrong code reuse (through inheritance) but then
again you (I) gain nothing from the other way around.
thanks
MihailNaydenov
----- Original Message ----
> From: BRM <bm_witness at yahoo.com>
> To: qt-interest at qt.nokia.com
> Sent: Tue, December 28, 2010 4:54:54 PM
> Subject: Re: [Qt-interest] QThread event loop running in main thread?
> ...
> Now, I'm not saying that this "proper" way is The Right Way for all instance -
>
> it's not. You've certainly shown a use case where having a wrapper class is
> certainly part of the design to manage the work of the worker thread, and
>that's
>
> perfectly fine. But you don't have to do so by deriving that handler class
>from
>
> QThread, so you could make it a little simpler if you liked:
>
> class myThreadWorker : QObject {
> ...
> };
>
> class myThreadHandler : QObject {
> Q_OBJECT
> public:
> ...
> public Q_SLOTS:
> // public interface
> Q_SIGNALS:
> // signals going out
> void workerTerminate();
> ...
> protected Q_SLOTS:
> // signals received from the worker
> ...
> private:
> QThread workerThread;
> myThreadWorker worker;
> };
>
> myThreadHandler::myThreadHandler(QObject* _parent) : QObject(_parent) {
> worker.moveToThread(&workerThreader);
> // connect signals & slots
> connect(this,SIGNAL(workerTerminate()),&workerThread,SLOT(quit()));
> workerThread.start();
> }
> myThreadHandler::~myThreadHandler() {
> Q_EMIT workerTerminate();
> workerThread.wait();
> }
>
>
> You still get the same benefits you listed, but a little nicer paradigm - just
>
> as tightly coupled if you like but easy to move around at the same time.
>
> I do agree that it is hard to justify refactoring older code for the new
> paradigm - I'll get to it eventually, but it's certainly not a priority since
>it
>
> is working.
>
> $0.02
>
> Ben
>
>
> ----- Original Message ----
> > From: Mihail Naydenov <mlists at ymail.com>
> > To: Thiago Macieira <thiago at kde.org>; qt-interest at qt.nokia.com
> > Sent: Tue, December 28, 2010 5:52:50 AM
> > Subject: Re: [Qt-interest] QThread event loop running in main thread?
> >
> > With the risk of being ashamed I must admit I do use the wrong way :)
> >
> > I still am not sold why should I not be doing it. I find the reasons
>against
>
> >it
> >
> > to academic - "Do the work in a object, devoted to that, and let a specific
> > class handle the threading part - encapsulation and specialization".
> > Well, merging the two is however to damn convenient in practice.
> >
> > The scenario I use (inspired by QFileSystemWatcher ) is to have Worker and
> > WorkerEngine.
> >
> > Worker is simple interface to the world (signals, slots, functions),
>manages a
>
> >
> > private WorkerEngine.
> > WorkerEngine is qthread and is lives on that thread.
> >
> > Worker queues work for WorkerEngine be invoking its methods, also handles
> > cancellation by calling its cancel/quit functions.
> >
> > WorkerEngine does all the work in Q_INVOCABLE functions, also sends results
>by
>
> >
> > invoking methods (in most cases the actual public result-signals), on the
> > Worker.
> >
> > Yes the design is "bad" because of the tight coupling of two, even three
> > classes, but to the world it is one - Worker, all other mess is impl.
>detail.
> > The important part however is - it can not be made simpler than that to
>have
>
> > threaded work done.
> >
> > Both reimpl run() and having separate qthread object to carry WorkerEngine
> > introduces some (uneeded) addition management.
> > In first case - to have a manual work queue;
> > In the second - to have stubs for communicating with qthread, you lose
> >sleep(),
> >
> > have (yet) another QObject allocation and management. Yes these are all
> >trival,
> >
> > but as I said - unnecessary, you gain nothing (at least I don't).
> >
> >
> > So in the end the scenario is by no means perfect, but cant be more
>simpler.
> >
> > Thanks
> > MihailNaydenov
> >
> >
> > ----- Original Message ----
> > > From: Thiago Macieira <thiago at kde.org>
> > > To: qt-interest at qt.nokia.com
> > > Sent: Tue, December 28, 2010 12:28:59 AM
> > > Subject: Re: [Qt-interest] QThread event loop running in main thread?
> > >
> > > On Monday, 27 de December de 2010 18:00:44 Hannu Shemeikka wrote:
> > > > Maybe you guys, Nokia or whoever is responsible, should update the
> > > > documents. Especially the QThread-stuff. It's written there that "to
> > > > create your own threads, subclass QThread and reimplement run()."
> > >
> > > Why?
> > >
> > > That is not wrong. It is accurate, even if not complete.
> > >
> > > Like Mihail said further down the thread, the wrong thing to do is to
>have
>
>
> > > slots in the class derived from QThread and/or using
moveToThread(this).
> > >
> > > If you treat the QThread object like I said, as the object managing an
> > > operating system resource (the thread), not the work to be done, you're
>
> >fine.
> > >
> > > --
> > > 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
> > >
> >
> >
> >
> > _______________________________________________
> > Qt-interest mailing list
> > Qt-interest at qt.nokia.com
> > http://lists.qt.nokia.com/mailman/listinfo/qt-interest
> >
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
More information about the Qt-interest-old
mailing list