[Interest] QTimer system goes down?

[Hugo Drumond Jacob]

Hi Thiago,

thanks for the help.

The SomeClassWorker's job is only a open/close on /dev/console and a ioctl
to pc speaker timer and play some tone. That is, the thread isn't waiting
for nothing (except the open/close).

I suspected of QTimer system because the main thread use some QTimers to
plot a real time waves and all waves freeze. Adding some qDebug() to
evaluate the QTimer events of real time waves plot object and nothing
happens after of problem mentioned previously.

Anyway, the problem was solved, but I don't know your origin.

Oh, we talk last year at Linuxcon Brazil. We are developing some medical
devices using Qt, remember?

Hugo Drumond Jacob
Eng. de Controle e Automação - CREA-MG 143908/LP
Mestrando em Modelagem Matemática e Computacional - CEFET/MG
hugo at jacob.eng.br | hugodj at gmail.com
+55(31)85244245


2012/10/3 Thiago Macieira <thiago.macieira at intel.com>

> On quarta-feira, 3 de outubro de 2012 10.44.56, Hugo Drumond Jacob wrote:
> > Hi folks!
> >
> > A couple of days ago I had some problems with a scenario like that shown
> > below:
> >
> > class SomeClassWorker : public QObject {
> >     Q_OBJECT
> >
> >     public:
> >         SomeClassWorker(QObject* parent = 0) : QObject(parent) {
>
> someTimer is initialised by the QTimer default constructor, which means it
> has
> no parent.
>
> >             connect(&someTimer, SIGNAL(timeout()), this,
> > SLOT(timeoutSlot()));
> >     someTimer.start(100); //Do something every 100msecs.
> >         }
>
>
> >             worker = new SomeClassWorker(this);
> >
> >             if(worker) {
> >                 worker->moveToThread(&workerThread);
>
> This does not move the timer to the other thread. Therefore, it is running
> on
> the current thread and the connection will be QueuedConnection.
>
> > The SomeClass instance is running in main thread and the SomeClassWorker
> is
> > running in a different thread.
>
> Not all of it.
>
> > Note that, on SomeClassWorker's constructor,
> > the "someTimer" is connected to a private slot "timeoutSlot()" with
> > Qt::AutoConnection connection type. On SomeClass's constructor, the
> > SomeClassWorker is moved to her thread. Note yet that someTimer is a
> > private member of SomeClassWorker and your parent is NULL (the default
> > QTimer's constructor is called).
>
> That's what I said :-)
>
> > >From Qt 4.8.0 documentation, the Qt::AutoConnection's description is:
> > "(default) If the signal is emitted from a different thread than the
> > receiving object, the signal is queued, behaving as Qt::QueuedConnection.
> > Otherwise, the slot is invoked directly, behaving as
> Qt::DirectConnection.
> > The type of connection is determined when the signal is emitted."
> >
> > So, when SomeClassWorker is moved to her thread, the someTimer still in
> > main thread and for every "timeout()" signal emitted, the "timeoutSlot()"
> > is queued called.
>
> Yup, your understanding is correct.
>
> > The problem: for some reason, the Qt timer system goes down (is correct
> say
> > this, in this way?). The main thread still running, but, all
> > "QTimer::timeout()" events aren't delivered.
>
> I'm pretty sure that you've gone wrong with your analysis here. Since the
> timer is running in the main thread, the signals are delivered by way of
> the
> queued connection. That means two threads are running and communicating.
> We've
> just doubled the number of potential problems:
>
>  - is the originating thread blocked, waiting for something?
>  - is the thread you started blocked?
>
> > To "solve" that, I set the someTimer parent to "this", in
> SomeClassWorker's
> > constructor:
> > PS: Note the quotation marks at solve.
> >
> >     SomeClassWorker(QObject* parent = 0) : QObject(parent),
> someTimer(this)
> > {
> >
> > So, anyone can tell me what is wrong or what is happening?
>
> We don't know what's wrong because the problem is in parts of the code that
> you did not paste. That is, it's in the "everything else" part of your
> application.
>
> However, moving the timer to the auxiliary thread makes most sense. That
> thread will handle its own events, avoiding a context switch for the simple
> timeout.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121003/bc181167/attachment.html>