ISSUE-826 RE: More Problems with Preemption

Gavin,
As David indicated in his email, both transitions are in fact type 3 transitions with respect to the most narrowly containing <parallel> states, so the first preempts the second.  It's clear that our definition/explanation needs to be tightened up, but this specific case is not a problem for the definition of preemption.


-          Jim

From: Gavin Kistner [mailto:phrogz@me.com]
Sent: Wednesday, February 06, 2013 5:27 PM
To: www-voice@w3.org; www-voice@w3.org
Cc: Chris Nuernberger
Subject: More Problems with Preemption

A colleague of mine created a pathological preemption case to show problems with the current system. Consider:

<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0">
  <parallel id="p0">
    <onentry><raise event="e"/></onentry>
    <state id="s0">
      <parallel id="p1">
        <state id='p1s0'><transition event='e' target='s0a'/></state>
        <state id='p1s1'><transition event='e' target='s0b'/></state>
      </parallel>
      <state id="s0a"/>
      <state id="s0b"/>
    </state>
  </parallel>
</scxml>

The event 'e' causes both transitions to be chosen by selectTransitions(). Both are 'type 2' transitions, and so the logic in preemptsTransition() causes neither to preempt the another. Both transition targets are entered, and now the state machine is in an invalid configuration where both s0a and s0b are active.

Is there a simple fix to the preemption logic for this? Or do we need to consider to simpler, more robust solution for determining whether the subgraphs affected by transitions overlap?

Received on Friday, 8 February 2013 14:17:07 UTC