[Bug 1055] State machine signalling on an operation causes multiple transitions

http://bugs.orocos.org/show_bug.cgi?id=1055

Peter Soetens <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Peter Soetens <[email protected]> 2014-03-13 23:07:36 CET ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > Created attachment 868 [details] [details] [details]
> > > Expands state machine unit test
> > > 
> > > Emitting v_event() in the following, while in STATE1, causes a transition to
> > > FINI. So v_event() has been taken in both STATE1 and STATE2, even though only
> > > one signal occurred.
> > > 
> > >     string prog = string("StateMachine X {\n")
> > >     + " initial state INIT {\n"
> > >     + "    transitions { select STATE1 }\n"
> > >     + " }\n"
> > >     + " state STATE1 {\n"
> > >     + "    transition v_event() select STATE2\n" // test signal transition
> > >     + " }\n"
> > >     + " state STATE2 {\n"
> > >     + "    transition v_event() select FINI\n"   // test signal transition
> > >     + " }\n"
> > >     + " final state FINI {} \n"
> > >     + "}\n"
> > >     + "RootMachine X x()\n";
> > > 
> > > Patch containing failing unit test attached.
> > > 
> > > Linking CXX executable state_test
> > > Running 16 test cases...
> > > ~/orocos_ws/src/orocos_toolchain/rtt/tests/state_test.cpp(822): error in
> > > "testStateOperationSignalTransition2": check "STATE2" ==
> > > sm->getCurrentStateName() failed [STATE2 != FINI]
> > > ~/orocos_ws/src/orocos_toolchain/rtt/tests/state_test.cpp(826): error in
> > > "testStateOperationSignalTransition2": check "STATE2" ==
> > > sm->getCurrentStateName() failed [STATE2 != FINI]
> > > 
> > > Demonstrated in Linux Mint 15.
> > 
> > Thanks for the unit test, I'm looking into it.
> 
> I have reproduced it and figured out why it is happening. Both event handlers
> are installed in the operation and emit'ed when the operation is called. The
> first event handler causes a transition which happens immediately (OwnThread!)
> and the next transition happens then as well because the state changed to the
> correct state.
> 
> We'll have to think of a way to prevent the second transition in the second
> event handler. The operation needs to call all call-backs since it can't know
> if it's all for the same state machine or different state machines etc.

I've pushed a clean solution to
https://www.gitorious.org/orocos-toolchain/rtt/merge_requests/32

- The event transition is not executed immediately, but scheduled. Gives the SM
a chance to perform the transition in a regular step()
- The event handles of STATE2 were setup way too early, even when being still
in STATE1, explaining the double reception

Commit msg offers some more detail. Unit test kept, passes now.

Peter

-- 
Configure bugmail: http://bugs.orocos.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev