commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Wienke <jwie...@techfak.uni-bielefeld.de>
Subject Re: [SCXML] onentry executable content parallel to further transitions
Date Tue, 02 Sep 2014 10:58:14 GMT
Hi,

On 08/29/2014 12:39 PM, Johannes Wienke wrote:
> we are currently evaluating commons scxml in the trunk version for our
> purposes. On thing that confused us is the fact that transitions from a
> state can already occur while that state's onentry executable content is
> still processing. Hence, we end up with more parallelism than expected.
> 
> Is this the intended behavior?
> 
> From the SCXML specification I actually cannot find anything that either
> allows or prevents this interpretation. So I am also curious how this
> behavior is justified wrt. to specs.

Following up on this: We have found a statement in the SCXML
specification that disallows the current behavior. In section 4.10 the
specification states:

"Note that SCXML treats the executable content triggered by a transition
as a single blocking operation and that no events are processed until
all the executable content has completed. For example, when taking a
transition into state S, the SCXML processor will not process any events
or take any transitions until all <onentry> handlers in S have finished."

This is definitely not the case right now when using multiple threads to
trigger events.

From a design point of view: why do the client threads that trigger
events directly process the whole event transition logic instead of
using an internal event queue and a processing thread as proposed by the
SCXML specification?

Cheers,
Johannes

-- 
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277


Mime
View raw message