[Interest] QEventLoop -- not sure I am correctly using this

Wed Dec 4 06:46:28 CET 2013

On Tue, Dec 3, 2013 at 10:39 PM, Jason Kretzer <Jason at gocodigo.com> wrote:

> Ah, I see!  Now I understand what you mean.
>
> I rewrote my “player” object to use a Qtimer that fires every 1 second and
> is started/stopped according to signals.  However, it still has the same
> problem where the timer won’t fire sometimes for extended periods.  I guess
> that means something in the overall eventloop is blocking it.  So, I
> believe I will try to implement it in the worker kind of format you have
> below where I can put the timer in a thread.
>

Also, as Thiago already suggested, while you're debugging, print out the
thread ID from the worker thread and main thread objects just so that you
know that they're running in different threads.

-mandeep

>
> I appreciate the help!
>
> -Jason
>
> *- - - - - - - - - - - - - - - - - - - - - - -*
> *Jason R. **Kretzer*
>
> *Application Developer*
> *Google # 606-887-9011 <606-887-9011>*
> *Cell # 606-792-0079 <606-792-0079>*
> *Jason at gocodigo.com <Jason at gocodigo.com>*
>
> *“quidquid latine dictum sit altum videtur”*
>
>
>
> On Dec 2, 2013, at 11:58 PM, Mandeep Sandhu <mandeepsandhu.chd at gmail.com>
> wrote:
>
> Hi Jason,
>
>
> As Andre pointed out, have an 'outer' class manage the worker object
> and thread for you instead of doing it from within your worker.
>
> Eg:
>
> SomeManagerClass::SomeManagerClass(QObject *parent) : QObject(parent)
> {
>    worker = new MyWorker(); // parentless
>    workerThread = new QThread(); // parentless
>
>    // Move worker object to new thread
>    worker->moveToThread(workerThread);
>
>    connect(worker, SIGNAL(workFinished()), this, SLOT(onWorkFinished()));
>
>    workerThread->start();
> }
> ...
> ...
> SomeManagerClass::~SomeManagerClass()
> {
>    workerThread->quit();
>    workerThread->wait();
> }
>
> As for you event loop, I don't see any obvious issues.
>
> I guess the reason you decided to wait for 1 second using an ev loop,
> rather than have a slot handle the timeout was to make the code look
> simple (synchronous)?
>
> What platform are you running this on?
>
> -mandeep
>
>
> On Tue, Dec 3, 2013 at 1:59 AM,  <andre at familiesomers.nl> wrote:
>
> Hi,
>
> It looks to me, that you're indeed doing it wrong. It seems you're
> trying to let your backgroundtaskmanager both manage a thread and be
> _in_ that thread. That is not the way to go. I'd separate the two
> issues. If you want the backgroundTaskManager to run in it's own thread,
> then either just make it a "front" for a backend implementation that you
> move to a thread managed by backgroundTaskManager, or just let let the
> whole backgroundTaskManager be unconcerned with what thread it runs in,
> and have whoever creates/owns/manages it be responsible for moving it to
> a separate thread if that is desirable.
>
> Then about your use of QEventLoop: no, I'd not use it this way.
> QEventLoop is not meant as an escape to 'pause' execution of your
> method. If you want to wait for about a minute, why not use a QTimer
> directly? I don't see a need for QEventLoop here at all.
>
> As to why your setup doesn't work and your eventloop seems blocked
> during your background task: I guess you gave your BackgroundTaskManager
> a parent object? That won't work. A whole parent/child tree must live in
> the same thread. So, I guess your BackgroundTaskManager did not actually
> get moved to the thread at all.
>
> André
>
>
> Jason Kretzer schreef op 02.12.2013 20:27:
>
> Maybe that last bit would be a bit more clear.
>
> The first qDebug statement writes out — I have it set to give the
> time when it is written as well — but the qDebug does not write
> until after the heavy task is completed in backgroundtaskmanager. Any
> other time, this performs as expected, ticking along every second.
>
> -Jason
>
> _- - - - - - - - - - - - - - - - - - - - - - -_
> _JASON R. __KRETZER_
> _ _
> _APPLICATION DEVELOPER_
> _Google # 606-887-9011_
> _Cell # 606-792-0079_
> _Jason at gocodigo.com_
> _ _
> _“QUIDQUID LATINE DICTUM SIT ALTUM VIDETUR”_
> _ _
>
> On Dec 2, 2013, at 2:14 PM, Jason Kretzer <Jason at gocodigo.com> wrote:
>
> Good Day,
>
> I have in my application, two classes. When the application starts
> up, one of the classes -backgroundtaskmanager - gets instantiated.
> In the constructor, a QTimer is started to timeout every 5 minutes
> and call runTasks. The instantiation is then moved to a separate
> thread so that it can run without impacting the rest of the
> application.
>
> Here are the contents of the constructor.
>
> QTimer* timer = new QTimer(this);
> connect(timer, SIGNAL(timeout()), this, SLOT(runTasks()));
> timer->start(300000); //fiveminutes
> thread = new QThread();
> this->moveToThread(thread);
> thread->start();
>
> The second class -player- is instantiated in the main thread. Once
> it is instantiated, it begins doing other tasks. Basically, a method
> is called with the following code. This code is designed to make the
> while loop delay for one second before executing the rest of the
> loop (one second-ish, I know it is not perfect but it has good
> enough resolution for what I need).
>
> while(!taskQueue.isEmpty()) {
> qDebug() << “BEFORE QEVENTLOOP”;
> QEventLoop wait1Sec;
> QTimer::singleShot(1000, &wait1Sec,SLOT(quit()));
> wait1Sec.exec();
> aDebug() << “AFTER QEVENTLOOP”;
>
> QList<Task*> instances;
> for(int t=seconds; t>previousTime; t—) {
> QList<Task*> vals = taskQueue.values(t);
> while(!vals.isEmpty()) {
> instances.insert(0, vals.takeLast());
> }
> taskQueue.remove(t);
> }
> previousTime = seconds;
> miliSeconds = QDateTime::currentMSecsSinceEpoch() -
> today.toMSecsSinceEpoch();
> seconds = miliSeconds/1000;
> }
>
> NOTE: the two sets of tasks these do are not related.
>
> So, anyway, every 5 minutes the tasks in backgroundtaskmanager are
> run. Some of these tasks can take up to a minute. When the
> backgroundtaskmanager class runs a task that does take this long
> (remember it is in a separate thread), the player class code above
> gets hung in what appears to be the inside of the QEventLoop. The
> qDebug statements don’t write out until the tasks in the
> backgroundtaskmanager are finished. Then it rushes through to catch
> up.
>
> My question is, am I correctly doing this at all? Is this the proper
> use of a QEventLoop?
>
> Thanks!
>
> -Jason
>
> _- - - - - - - - - - - - - - - - - - - - - - -_
> _JASON R. __KRETZER_
> _ _
> _APPLICATION DEVELOPER_
> _Google # 606-887-9011_
> _Cell # 606-792-0079_
> _Jason at gocodigo.com_
> _ _
> _“QUIDQUID LATINE DICTUM SIT ALTUM VIDETUR”_
> _ _
> <image001.png>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> 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/20131204/86740353/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13452 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131204/86740353/attachment.png>