QObject::killTimers() warning after timer stopped from its own thread

[astodolski]

I've compiled a complete application with the changes that have been posted in this thread. It's possible as you have suggested that the app is attempting to stop the timer before the thread completes.

test app attached here ->> workerTest.zip

[wysota]

Does the code you posted still contain the bug? I'm not getting any warnings.

[astodolski]

Does the code you posted still contain the bug? I'm not getting any warnings.

The code example I posted still reports the warning message. Are you able to compile and run it? I am using 4.8.4 with Win SDK 7.1 compiler under Creator 2.6

[wysota]

I'm not getting any warnings. I use Qt 4.8.3 x64 Linux. Same output with Qt 5.0 RC2.

$ ./FlashWizard
Main thread: QThread(0xcde710)
Worker Object Thread Id: QThread(0x7ffff75eff00)
Now using thread: QThread(0x7ffff75eff00)
1
2
3
...
97
98
99
100

[astodolski]

I'm not getting any warnings. I use Qt 4.8.3 x64 Linux. Same output with Qt 5.0 RC2.

Oh I guess the problem wasn't fully realized. It's only when you click the cancel button before the loop finishes that the message is shown - sorry. I should have re-iterated that. I though that was evident within the thread.

[wysota]

Still, no warning

An idea: maybe you shouldn't be using a thread at all? What do you need it for?

[astodolski]

Still, no warning

An idea: maybe you shouldn't be using a thread at all? What do you need it for?

So let me understand. You run this app. Before the count gets to 100, hit the brakes with the Cancel button. You're telling me no message like "QObject::killTimer: timers cannot be stopped from another thread"?

This is a stripped out app that is used as a prototype for use with a hardware DLL. That library has functions that are called for each timer tick and have to perform tasks in the background that would otherwise tie up the UI. I created this to perform a task (a loop counter in this case) and update a progress bar. I find it incredible that this test app loaded on a host PC and on a virtual machine and on my own laptop all perform exactly the same - that is, the killTimer warning is displayed in the debug window after the Cancel button is clicked and before the counter gets to 100, except for you.

I read your article on keeping the UI responsive as well as general considerations when making calls to hardware while updating a UI with background workers. I feel that background tasks belong in another thread so as to keep the UI responsive. That's my reason for this prototype. That's pretty much boilerplate practice. I don't have a Linux distro prepared for testing on there.

[wysota]

So let me understand. You run this app. Before the count gets to 100, hit the brakes with the Cancel button. You're telling me no message like "QObject::killTimer: timers cannot be stopped from another thread"?

Nope. The last thing I get is a number. Maybe I should wait an hour for the message to appear

That library has functions that are called for each timer tick and have to perform tasks in the background that would otherwise tie up the UI.

It doesn't yet mean you need to do any threading.

I created this to perform a task (a loop counter in this case) and update a progress bar. I find it incredible that this test app loaded on a host PC and on a virtual machine and on my own laptop all perform exactly the same - that is, the killTimer warning is displayed in the debug window after the Cancel button is clicked and before the counter gets to 100, except for you.

Do you want me to shoot a video? Maybe the thing is that you're using Windows and I'm not (however I doubt it).

I feel that background tasks belong in another thread so as to keep the UI responsive.

You can always delegate the task to an external process and talk to it using QProcess or QLocalSocket. However I still think threading is not required here, especially if it's a source of some problems. Nevertheless I think the code you have is easy to fix to work within a thread. Maybe you just need to restructure the code.

[astodolski]

You can always delegate the task to an external process and talk to it using QProcess or QLocalSocket.

My DLL is only functions in a library. It is not an external program which is what QProcess takes care of. QLocalSocket would be helpful but not really what I need.

Your article even supports threads for external libraries http://doc.qt.digia.com/qq/qq27-resp...gaworkerthread

However I still think threading is not required here, especially if it's a source of some problems.

But not necessarily a Qt bug.

Nevertheless I think the code you have is easy to fix to work within a thread. Maybe you just need to restructure the code.

I still think this is viable if I can get the thread stopped properly. That is what was previously suspected.

[wysota]

I still think this is viable if I can get the thread stopped properly. That is what was previously suspected.

A possible fix is very easy. Use QObject::startTimer() and QObject::killTimer() instead of an external QTimer instance.

void MyWorker::start() { m_tid = startTimer(100); } // slot
void MyWorker::stop() { killTimer(m_tid); } // slot
void MyWorker::timerEvent(QTimerEvent *ev) {
  if(ev->timerId() == m_tid) doWork();
  else QObject::timerEvent(ev);
}

void MyWorker::start() { m_tid = startTimer(100); } // slot
void MyWorker::stop() { killTimer(m_tid); } // slot
void MyWorker::timerEvent(QTimerEvent *ev) {
  if(ev->timerId() == m_tid) doWork();
  else QObject::timerEvent(ev);
}

To copy to clipboard, switch view to plain text mode 

[astodolski]

A possible fix is very easy. Use QObject::startTimer() and QObject::killTimer() instead of an external QTimer instance.

void MyWorker::start() { m_tid = startTimer(100); } // slot
void MyWorker::stop() { killTimer(m_tid); } // slot
void MyWorker::timerEvent(QTimerEvent *ev) {
  if(ev->timerId() == m_tid) doWork();
  else QObject::timerEvent(ev);
}

void MyWorker::start() { m_tid = startTimer(100); } // slot
void MyWorker::stop() { killTimer(m_tid); } // slot
void MyWorker::timerEvent(QTimerEvent *ev) {
  if(ev->timerId() == m_tid) doWork();
  else QObject::timerEvent(ev);
}

To copy to clipboard, switch view to plain text mode 

Thanks anyway. This didn't change anything. I changed the slots in the worker as shown. No improvement. Perhaps another viewer running Windows can try the sample I posted with the changes mentioned since it seems to be Windows only related.

[wysota]

You shouldn't be getting that error with the code I posted. Unless maybe you delete the worker object from within a wrong thread (if it gets deleted at all). Try cleaning and rebuilding the project from scratch.

[astodolski]

You shouldn't be getting that error with the code I posted. Unless maybe you delete the worker object from within a wrong thread (if it gets deleted at all). Try cleaning and rebuilding the project from scratch.

Done that. Still as is. Should I post the updated project?

BTW for reference, it seems as others have experienced the same on Windows though I dont know any further detail.
http://qt-project.org/forums/viewthread/22916

I found something that may be helpful.

With all the current changes, I note that the stop slot gets called twice. The first time through the current thread is the main thread - hence the message. The second time through the current thread is the worker thread.

In line 957 of qeventdispatcher_win.cpp

thread() != QThread::currentThread;

We get here from killTimer which calls unregisterTimer.

Note that on a Linux system, you may never get to that line of code because it is in a different module altogether.