RE: [SCXML] Algorithm mainEventLoop and the internalQueue

Philipp,
  You are right.  This is a bug and will be fixed in the next public
draft.  It should not matter whether the internal event triggers a
transition or not - all queued internal events should be processed
before the macrostep terminates.

Thanks for pointing this out.

- Jim

-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of Philipp Kolhoff
Sent: Monday, July 27, 2009 3:55 PM
To: www-voice@w3.org
Subject: [SCXML] Algorithm mainEventLoop and the internalQueue

(Sorry for duplicates, I did not use my registered email before)
Hi there,
I've been working with Statecharts and esp. SCXML for a longer time now.

I started implementing an interpreter in C# and C++ first for my 
Diploma-Thesis, which got then published in "Game AI Wisdom 4" and later

found use in my companies Point&Click-Adventure Engine. Now i started to

work on an interpreter written in ActionScript to get a library that any

Flex developer can slap into her RIA/game. So when I came back I found 
the description of the Algorithm for interpreting SCXML's and that was a

great help to re-implement my interpreter.
However I stumbled upon a part in the mainEventLoop after implementing 
it and running some Test-SCXML's... maybe I did not get it right, but I 
think there maybe a mistake:

Take a scxml snipplet like this:

<parallel id="InTest">
 <state id="s1">
     <initial>
        <transition target="s11"/>
     </initial>
     <state id="s11"/>
     <final id="s12"/>
 </state>
 <state id="s2">
     <initial>
        <transition target="s21"/>
     </initial>
     <state id="s21"/>
     <final id="s22"/>
 </state>
 <transition event="InTest.Done" target="f"/>
</parallel>

.......

// now take any newly enabled null transitions and any transitions 
triggered by internal events
macroStepComplete = false;
until(macroStepComplete):
    enabledTransitions = selectEventlessTransitions()
    if (enabledTransitions.isEmpty()):        internalEvent = 
internalQueue.dequeue()// this call returns immediately if no event is 
available
       if (internalEvent):
          datamodel.assignValue("event", internalEvent)
          enabledTransitions = selectTransitions(internalEvent)
           if (enabledTransitions):
       microstep(enabledTransitions.toList()
    else:
       macroStepComplete = true
......

Suppose during the execution of an external event more than one internal

event is queued. This happens often if a parallel-state is "Done" and 
its children are as well. In the case listed above, there would be 
generated the events s1.Done, s2.Done and InTest.Done in that order (if 
proper transitions would exist and the events would be fired). During 
the next macro step, the first internalEvent is dequeued ("s1.Done"), 
but no transition will be enabled. That would mark the macroStep as 
complete and no other internal event is handled until the next external 
event is dispatched.
Imho, there should be done something like this more likely:

if (enabledTransitions):
  microstep(enabledTransitions.toList()
else:
  macroStepComplete = internalQueue.isEmpty()

So, if the internalQueue is not empty, the macrostep will dequeue the 
next event in the internal queue.

Any opinions?

Best regards,
Philipp Kolhoff




					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

Received on Thursday, 30 July 2009 22:33:11 UTC