qthread / qtimer

[Galen]

edit: sorry, figured this one out so I'm changing the topic. I'd like to be able to stop and start this qtimer from within the timeoutHandler slot, but doing so gives errors about killing a timer from a different thread. The code below is just an example and in the real deal it would check a shared variable (modified by the parent) for a pause request, then use QMutex and QWaitCondition to control the pause. Does this sound like something that should even be possible in the first place? I've gotten around this by having the parent control the QTimer externally, but I'd rather all the load be in the child thread.

QObject::killTimer: timers cannot be stopped from another thread"
QOBject::startTimer: timers cannot be started from another thread"


void ThreadWatcher2::run() {
updateTimer = new QTimer();

QSignalMapper signalMapper;

for (int i=0; i<6; i++) {
connect(thread[i], SIGNAL(finished()), &signalMapper, SLOT(map()));
signalMapper.setMapping(thread[i], i); }

connect(&signalMapper, SIGNAL(mapped(int)), this, SLOT(finishedHandler(int)));

connect(updateTimer, SIGNAL(timeout()), this, SLOT(timeoutHandler()));

updateTimer->start(10);

QThread::exec();
}
void ThreadWatcher2::timeoutHandler() {
for (int i=0; i<6; i++)
window[i]->update();

updateTimer->stop();
updateTimer->start(10);

if (threadsLeft==0)
QThread::exit(0);
}
void ThreadWatcher2::finishedHandler(int t) {
threadsLeft--;
QTextStream cout(stdout, QIODevice::WriteOnly);
cout << "t: " << t << endl;
}

[wysota]

I don't know what your ThreadWatcher2 class does but if I understand it correctly, you don't need it. The main thread can easily do its task. Just connect the finished() signal from each thread to a slot (you don't need a signal mapper) in the main thread, where you will reduce the remaining thread count. When that reaches 0, you will know the task is completed. You shouldn't need to periodically update() your window - the window should be notified it should update itself by something that actually changes what is displayed in the window. The third thing is that you forgot that QThread object doesn't live in a thread it represents so there is a good chance your slots were executed in the context of a wrong thread leading to a race condition you might be experiencing.

[Galen]

Sorry, I realized what was wrong and changed the post (needed to start the threadwatcher before the sort threads or some of the sorters exited before the connections were even made) to something completely different since I can't delete the topic.

Originally I did have the sorters calling updates, but I realized they would go through the roof when there is no delay, when certainly updating more than 100x a second (which can be accomplished using a 10ms timer) was not necessary. Perhaps I should not be concerned on that count though?

[Galen]

Anyone? I guess my question is do slots not run in the same thread despite being defined in the same class? Or is there some sort of scope issue here?

thanks

[wysota]

Read my post again, the answer is there.

[Galen]

Oh, right sorry... looks like you discussed this over here too.

http://www.qtcentre.org/threads/26402-Executing-slots-in-a-separate-QThread