This slot won't be triggered, because you block the event loop with "workerThread->wait()" and timer event can't be processed. Try sending an event to that thread.Originally Posted by 0xBulbizarre
This slot won't be triggered, because you block the event loop with "workerThread->wait()" and timer event can't be processed. Try sending an event to that thread.Originally Posted by 0xBulbizarre
0xBulbizarre (19th March 2006)
Ok, thank you for that one.Originally Posted by jacek
In fact, I wanted to avoid a connect() to do only 1 emit, that's why I used the one shot timer. Is there a way (1 liner) to trigger a slot of another thread?
You can also certainly explain me that one. Similar problem as describved above, but in the worker thread. The threadProgressing() signal (Qt::QueuedConnection) is only received by the GUI thread when the worker thread returns to the event loop. Is emit effectively only happening in the event loop?
Qt Code:
// code executed by workerThread // this is the slot called from the GUI thread (see post above) void OtherThread::stopThread(void) { starting = false; for (int i = 100; i > 0; i--) { msleep(100); emit threadProgressing(i); // uncommenting following line solves the problem, what is the best practice here ? //QCoreApplication::processEvents(); } emit threadStopped(); quit(); }To copy to clipboard, switch view to plain text mode
Thank you
You could try to send QMetaCall event, but it probably won't fit in one line. Maybe you could add a boolean flag and some method that sets it when thread should stop itself?Originally Posted by 0xBulbizarre
The docs say:Originally Posted by 0xBulbizarreUnless something has changed in Qt 4.1.1, sender doesn't even need to live in a thread with a running event loop (see the Mandelbrot example --- there's no event loop running in RenderThread).With queued connections, the slot is invoked when control returns to the event loop of the thread to which the object belongs. The slot is executed in the thread where the receiver object lives.
Originally Posted by 0xBulbizarreMy problem here is that (it seems) the signal is not sent until control returns to the event loop of the _sender_, although the receiver is in its event loop during all that time.Originally Posted by jacek
Do you actually start that second thread?Originally Posted by 0xBulbizarre
Yes (of course), the second's thread run() method is :Originally Posted by jacek
Do you want some test code to experiment with, do you need more infos ?
That's the run() method, but how do you start that thread?Originally Posted by 0xBulbizarre
I start it from gui thread withOriginally Posted by jacek
Qt Code:
otherThread = new OtherThread(this); otherThread->start();To copy to clipboard, switch view to plain text mode
OtherThread's declaration:
Qt Code:
To copy to clipboard, switch view to plain text mode
Looks OK, did you try with 0 instead of "this"?Originally Posted by 0xBulbizarre
yes, but nothing changes (apparently).Originally Posted by jacek
I think I found something... The slot executed by the singleShot timer shall be executed by the worker thread, but is in fact executed by the GUI thread. So, I deduce that the connection created by the singleShot timer is a DirectConnection instead of a QueuedConnection. That would explain why the slot is executed by the emitting thread.
Here is how I create the worker thread, and how I create the singleShot() timer
Qt Code:
// code from the GUI thread otherThread = new OtherThread(this); otherThread->start(); cout << "In GUI Thread, Thread=" << currentThread() << " ThreadID=" << currentThreadId() << endl;To copy to clipboard, switch view to plain text mode
here is my startThread() function (from the worker thread)
Qt Code:
void OtherThread::startThread(void) { cout << "In startThread() Thread=" << currentThread() << " ThreadID=" << currentThreadId() << endl; // do some job... }To copy to clipboard, switch view to plain text mode
outputs where we can see that the GUI thread executes the slot instead of the worker thread:
In GUI Thread, Thread=0x804f198 ThreadID=3078543040
In startThread() Thread=0x804f198 ThreadID=3078543040
Where is my mistake ? should QTimer::singleShot()'s receiver be something else that my otherThread ?
I saw in the docs that:
If we look at my code above (reproduced below)... we can see that both the sender and the receiver live in the same thread. The sender is the singleShot timer, the receiver is a thread object, also living in the GUI thread.By default, QObject::connect() establishes a direct connection if the sender and the receiver live in the same thread, and a queued connection if they live in different threads.
Qt Code:
otherThread = new OtherThread(this); otherThread->start();To copy to clipboard, switch view to plain text mode
is it correct ? how to solve that problem ?
QThread object lives in the thread that created it. You could split that class into two --- the thread itself and an object that lives within that thread.
0xBulbizarre (20th March 2006)
Bookmarks