[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