[Qt-interest] QWaitCondition prevents signals from calling slots

[Jonathan Wong]

> Timers depend on the event loop running. And if the thread is blocked on a
> wait condition, then it's not running the event loop (the inverse is also
> true: if the event loop is running, then we're not waiting on a wait
> condition).

Ah, elegantly explained. Thanks!

So is it true that QTimer needs the event loop to be running in order to function? Say QTimer in
threadA, so threadA must not be blocked (or waiting on QWaitCondition).

I've done up a pretty exhaustive, albeit probably somewhat wrong, example to show the theory
above. There are exceptional cases.

Can you help me look at it? There's simple GUI, and lots of explanatory text in output for just
about every case.

The exceptional case to try is this:

threadA blocked, main thread blocked (via objectB's waiting), QTimer in threadC unblocked.

That didn't function as per the theory about QTimer needing a running event loop. threadC is not
blocked at all.

It does seem that the theory doesn't apply whenever the main thread is blocked. Seems like it is a
terrible thing to do, blocking main thread?

> One more thing: avoid having slots in the QThread-derived class itself.
> Remember that the QThread-derived object is created in another thread (it
> can't be created on its own thread because that thread isn't running
> yet!), so it has thread affinity to the creating thread. That may cause
> unexpected behaviour, so the recommendation is to avoid it.

Yes, I suppose you saw I was trying to parent the QTimer in ThreadA? :)

I suppose the slots for a QThread-derived class would be called in another thread (not the class's
run() thread).


Thiago Macieira wrote:
> Jonathan Wong wrote:
>> Actually, further tests showed that a thread can both wait on a
>> QWaitCondition and wait for incoming signals to its slots. But this
>> thread must be a different one from the thread emitting the signals.
>>
>> 1. ThreadA waits on a QWaitCondition.
>> 2. ThreadA also has a slot someSlot.
>> 3. Main thread starts a QTimer (to fire after ThreadA started waiting).
>> 4. QTimer successfully sends signal to someSlot.
>> 5. someSlot wakes on the QWaitCondition.
>> 6. ThreadA gets woken up from the wait in step 1.
>>
>> The doesn't happen if the same thread does all 3 things:
>>
>> 1. Wait on a QWaitCondition.
>> 2. Has a slot someSlot that wakes up the wait.
>> 3. Has a QTimer that fires a signal to someSlot.
> 
> It's the same explanation as before.
> 
> Timers depend on the event loop running. And if the thread is blocked on a 
> wait condition, then it's not running the event loop (the inverse is also 
> true: if the event loop is running, then we're not waiting on a wait 
> condition).
> 
> The difference between your first and second cases above is which thread has 
> the timer. A timer is basically a way to ask the event loop to send you an 
> event after timeout. So you can only use timers from threads that are 
> running event loops. This restriction is exactly because of the problem 
> you're seeing: if the thread isn't running an event loop, then the timer 
> will never be processed.
> 
> One more thing: avoid having slots in the QThread-derived class itself. 
> Remember that the QThread-derived object is created in another thread (it 
> can't be created on its own thread because that thread isn't running 
> yet!), so it has thread affinity to the creating thread. That may cause 
> unexpected behaviour, so the recommendation is to avoid it.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: QWaitSignalsTest.7z
Type: application/octet-stream
Size: 4198 bytes
Desc: not available
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090520/a53b6d39/attachment.obj