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
signature.asc
Description: OpenPGP digital signature
