[Qt-interest] QSignalTransition drops silently signals

Peter Kümmel syntheticpp at gmx.net
Fri Jun 24 15:24:53 CEST 2011


On 16.06.2011 19:28, Bo Thorsen wrote:
> The only reasonable explanation I have for this is if your signal slots
> are direct.
>

Here it was a function called in onTransition() which triggered a reply
from another thread, but this signal was dropped because it was not connected.


> You can test this by creating a proxy object in the gui thread like this:
>
> class ProxyObject : public QObject {
>       ...
> signals:
>       void retransmit();
> };
>
> ...
>
> // This MUST be done by objects in the GUI thread

I assume you mean the thread of the state machine.

> connect(otherThread, SIGNAL(toT2()), new ProxyObject(this),
>       SIGNAL(void retransmit()), Qt::QueuedConnection);
>
> If this turns out to be a problem, it looks to me like you should send a
> bug report. If this does not fix the problem, then you have to look in
> your own code for it.

Good idea, my workaround does effectively the same (it uses postEvent)

Peter


>
> The proxy signal with the queued connection works by not handling the
> emit before the event loop runs again. Since the event loop is in the
> same thread as the state machine, the signal can not be lost.
>
> Bo.
>
> Den 14-06-2011 21:09, Peter Kümmel skrev:
>> Recently I used the QStateMachine framework in a more complex
>> than "animation-on-ui-event "multi-threaded environment and stumbled
>> over a strange behavior of QSignalTransition, which at the first glace
>> looks like a design error in QSignalTransition (haven't checked the
>> other subclassesof QAbstractTransition).
>>
>> Assume following setup:
>>
>> QStates:
>>        s1, s2, s3
>>
>> QSignalTransitions
>>        t1: s1->s2 and t2: s2->s3
>>        t1 and t2 are triggered by objects of another thread than QStateMachine ones
>>
>> Then this is possible:
>> The state machine makes the transition from s1 to s2 because t1 was triggered,
>> and while the state machine is busy with t1 the signal which should trigger t2
>> is also emitted by an object (this is possible because the emitting object runs in a other thread).
>> But because the connections of t2 to the signal is not created until s2 is entered,
>> the signal for t2 is ignored and silently dropped. No deferring, no warning, nothing,
>> the state machine simply will never leave t2.
>>
>> Here I wonder if this is a bug or a feature?
>>
>> Peter
>>
>>
>> P.S.:
>> Recently I also threw it into the black hole:
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at qt.nokia.com
>> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
>
> Bo Thorsen,
> Fionia Software.
>



More information about the Qt-interest-old mailing list