| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
Hi, what would the following piece of code do, assuming it runs in the Qt Main (GUI) Thread: QThread * thr = new mythread(); // mythread is a subclass of QThread connect(thr, SIGNAL(someSignal()), this, SLOT(someSlot())); emit someSignal(); // Signal 1 thr->start(); // exec() is called in mythread::run() emit someSignal(); // Signal 2 The executed slot after Signal 1 should run in the Main thread (since no other OS thread exists yet). Does the slot invoked by Signal 2 then run in the now existing new thread, i.e., has the signal/slot connection changed from a direct connection to a queued connection after the start()-call? Is it necessary to call exec() in a thread's run method to be able to use signals and slots? Regards, Harald -- [ signature omitted ]
On Monday 17 March 2008 11:11:43 Harald Grossauer wrote: > QThread * thr = new mythread(); // mythread is a subclass of QThread > connect(thr, SIGNAL(someSignal()), this, SLOT(someSlot())); > emit someSignal(); // Signal 1 > thr->start(); // exec() is called in mythread::run() > emit someSignal(); // Signal 2 The two QObjects in the above example (this and thr) belong to the same thread. So the connection is DirectConnection. > The executed slot after Signal 1 should run in the Main thread (since no > other OS thread exists yet). No. It's executed in the main thread because it's a direct connection. > Does the slot invoked by Signal 2 then run in > the now existing new thread, i.e., has the signal/slot connection changed > from a direct connection to a queued connection after the start()-call? No, it also runs in the main thread. The connection type did not change. It only changes when one of the two objects (sender or receiver) move threads using moveToThread. Since you did not show us any code indicating that you called that function, I must assume you did not. > Is it necessary to call exec() in a thread's run method to be able to use > signals and slots? Yes. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Monday 17 March 2008 13:00:19 Harald Grossauer wrote: > Okay, but if emit someSignal() in the mythread::run() method (i.e., from > within the newly created thread), then the slot is executed in the main > thread, isn't it? At least that's what is said in the Mandelbrot example. No. The connection is a DirectConnection regardless of where you emit the signal from. The connection type is determined by which thread the object belongs to. And since you did not call moveToThread, both objects belong to the thread they were created in: the main thread. So if you call emit someSignal() inside the thread, it'll emit the mythread::someSignal() signal. But since the connection is Direct, the signal will be delivered in the thread it was emitted in, which is not what you want. This topic appears very, very often: the QThread object does NOT live in its own thread. The QThread object belongs to the thread that created it. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Please reply to the list, not to me. On Monday 17 March 2008 13:14:55 Harald Grossauer wrote: > Sorry, but you write directly contradicts what is written in the > documentation of the mandelbrot example > http://doc.trolltech.com/4.3/threads-mandelbrot.html Hmm... indeed. > In the first few paragraphs of the Section "MandelbrotWidget Class > Implementation" is says: > > "Although it looks like a standard signal-slot connection between two > QObjects, because the signal is emitted in a different thread than the > receiver lives in, the connection is effectively a queued connection. These > connections are asynchronous (i.e., non-blocking), meaning that the slot > will be called at some point after the emit statement. What's more, the > slot will be invoked in the thread in which the receiver lives. Here, the > signal is emitted in the worker thread, and the slot is executed in the GUI > thread when control returns to the event loop." > > > So what is correct? I have reviewed the code and the example is correct. The delivery mechanism for an AutoConnection is determined during the signal emission. So if the signal is emitted in a different thread -- even if the object doesn't live in that thread -- it'll be queued. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.