commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml] processing multiple events
Date Fri, 18 Nov 2005 18:51:32 GMT
On 11/18/05, Barnett, James <> wrote:
> I'm puzzled by the behavior of the scxml engine when I enter multiple events (separated
by spaces) at one time.  For example, when running the Standalone version with test script
transitions-01.xml, and in state 'ten', I would expect to be able to enter events 'ten.done
twenty_one.done twenty_two.done' and have the machine process all of them and go to state
'thirty'.  However, the system only takes the first transition, to state twenty/twenty_one.

Jim - Thanks for asking.

The space separated list is the list of events received between the
last trigger and the current one (this is the asynchronous time model
for state charts, where the engine reacts whenever an external event
is received -- as against the synchronous model where one step is
executed per unit time/clock tick). In fact, this does not imply any
temporal associations between the events being fired based on the
sequence in which they appear in the space separated list. Moreover,
all the events in the space separated list operate over the set of
candidate transitions that result from the ancestor closure of the
states that were active when the trigger was received i.e. all events
in a space separated list operate over the *same* ancestor closure.

The correct way to imply the temporal sequence that you refer to for
this SCXML example [1], therefore, is to fire events separately as
"ten.done", "twenty_one.done" and "twenty_two.done", in that order,
rather than a space separated list.

Note this does not mean the engine disregards multiple events when
fired at a time. You can verify that multiple events are accounted for
by specifying this list " ten.done" when in state
"ten", and observing that the appropriate transition for event
"ten.done" is indeed followed. A better example might be the trigger
"thirty_one_child_one.done thirty_two_child_one.done
thirty_three_child_one.done" right after entering the parallel and
noting that *each* of the orthogonal states follow their transitions.

> Looking at the code, I think that there is a  problem in triggerEvents in
 The method consists of a do loop, with each iteration through the loop processing a single
event.  However at the bottom of the loop, we have:

Each iteration is not processing one event, rather all events in that
trigger. Note that the constructor for Step takes the entire list of
events, not just the first one.

>            if (superStep) {
>               evs.clear();
>            }
>        } while(superStep && currentStatus.getEvents().size() > 0);
> so if 'superStep' is true, the event list is cleared (via 'evs.clear').  However, if
'superStep' is false, the 'while' condition will cause the loop to exit after the first iteration.
 So multiple events will never get processed.  I find that if I comment out both conditions
mentioning superStep, the multiple events do get processed and the system transitions to state

The superStep concept, and that bit of code, is orthogonal to the
space separated event list question you ask above. That bit of code
merely ensures that if the external triggers have caused any internal
events fired by the SCXML engine to be enqueued for processing, the
external trigger list be cleared so the external triggers are not
considered to have been "fired" once again when the engine takes a
stab at processing the internal events.

a) One only needs to continue iterating if the engine is processing
triggers as a superstep, and
b) One needs to continue iterating until the state machine reaches a
"stable" configuration, whereby all internal events have been
processed and the event queue has been exhausted.

> These complications may arise from the semantics of superStep and its interaction with
the Standalone environment.  The simplest change would be to change the upper condition to
'if (! superStep)...', but I would think that in that case the events should not be thrown
away, but rather left in the queue for further processing.

Indeed, if events were "thrown away" that'd lead to extremely
undesirable behavior. But, as pointed above, that is not the case.

> Or am I completely off base?
> - Jim
> P.S. I have been able to compile the code, thanks to the previous pointers to the commons-build
area.  Many thanks.

Thanks for the nudge :-) In addition, if you update your local SCXML
root from the Commons Sandbox repository, you won't need commons-build
anymore. I committed the related changes yesterday, and I also created
a "Building Commons SCXML" page [2].



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message