Re: Invoking on stable configuration but sending on entry

Stefan,
   What parts of invoke do you find confusing?  Much of the semantics of 
invoke can be derived from a couple of basic ideas:
   1.  We want invoke to be tied to a state.  It's roughly similar to 
the 'while' element in Harel state charts.  Hence the fact that invokes 
are triggered by entry into the state and cancelled upon exit.
  2.  The invoked process should be separate from the main state 
machine.  If you want a concurrent process running in the same state 
machine, use parallel states.

A couple of things follow from the fact that the invoked process is a 
separate process and is not necessarily an SCXML state machine at all:
a.  Its timing is indeterminate with respect to the main state machine.  
The only way to know when the invoked process is running is for it to 
tell you.
b.  There's no point in starting an invocation in a state that you will 
be leaving immediately.  (This point becomes particularly clear when you 
remember that in Harel state charts transitions are instantaneous.)  
Hence we wait for a stable configuration before triggering the 
invocations.  If we didn't it would be completely non-deterministic how 
much of the immediately cancelled invocations actually executed.

One other important feature (or maybe it's a lack of a feature...) stems 
from a more fundamental aspect of the semantics, namely that the data 
model in the invoked process must be completely separate from the one in 
the invoking process.  The reason for this is that Harel state charts 
(and SCXML) allow for transitions that are triggered solely by 
values/changes in the data model (that is, without any event trigger, 
things like cond="x==7")  It is difficult to implement this feature in a 
real-world system if external process can modify your data model without 
warning.  (Do you have to constantly poll for changes?)  Thus the 
semantics of SCXML are carefully arranged so that the data model can 
only be modified at specific points in the algorithm  -- namely while 
processing an event.  (There is a comment to this effect in the spec.)

Certainly there are ways to allow for a shared, externally modifiable, 
data model (for example, raise a special system event on data model 
modification, for example.)  However, the group felt that tackling this 
would delay us too much, particularly since none of us had a pressing 
need for a shared data model.  However this is just the sort of thing 
that we might consider for SCXML 2.0.

Returning briefly to the topic you raised below, a future version of 
SCXML could require the invoked process to raise an event as soon as it 
was started.  Or, without even waiting for a future version of SCXML, 
you could define an Event I/O Processor that would queue the event until 
the invoked process was up and running.

If these broad outlines don't answer your questions, please send me more 
detailed ones.

- Jim

On 2/25/2014 5:32 AM, Stefan Radomski wrote:
> Hi again,
>
> as the invoke semantics turn out to be a major source of confusion for 
> SCXML authors, we are scratching our heads as to why the group decided 
> for this particular semantics. Can we read up on the rationale somewhere?
>
> Best regards
> Stefan
>
> On Jan 20, 2014, at 16:36, Jim Barnett <1jhbarnett@gmail.com 
> <mailto:1jhbarnett@gmail.com>> wrote:
>
>> Stefan,
>> This is an interesting topic.  The group spent a lot of time 
>> discussing the timing of <invoke>.  We concluded, as David suggested, 
>> that the way to make information available as soon as the invoked 
>> process starts is to pass it as parameters.  If the invoking process 
>> needs to know when the invoked process actually starts, it's easy for 
>> the invoked process to do a send as soon as it starts.  (Then you put 
>> an event handler in the invoking process to send the event you want 
>> as soon as it gets the"I'm started" event.) We didn't make the "I'm 
>> started" event a requirement in the spec because a lot of 
>> applications don't need it.  Since it's easy to do in the markup, we 
>> decided to leave it to the application author.
>>
>> David is right that an error in a delayed send will cause the onentry 
>> block to be exited as soon as the send is evaluated.  (The error 
>> event will be placed in the queue and thus not processed till 
>> later.)  The relevant language in 6.2.3 is:
>>
>>  "The Processor /MUST/ evaluate all arguments to <send> when the 
>> <send> element is evaluated, and not when the message is actually 
>> dispatched. If the evaluation of <send>'s arguments produces an 
>> error, the Processor /MUST/ discard the message without attempting to 
>> deliver it."
>>
>> Please let us know if you think this topic needs further discussion.  
>> If you think it doesn't, or we do not hear from you by January 28th, 
>> we will proceed to publish the next version of the specification.
>>
>> - Jim
>>
>> On 1/20/2014 8:24 AM, David Junger wrote:
>>> Le 20 jan 2014 à 11:15, Stefan Radomski<radomski@tk.informatik.tu-darmstadt.de>  a écrit :
>>>
>>>> as we continue to use SCXML for various applications, there is one deficiency that always bugged us. Consider that you have a state that will invoke something and you’d like to send some event to it right-away. You cannot use <send target=“#_invokeid”> in an onentry element as the invoker will not yet exist, it is only invoked when a stable configuration is reached (see procedure mainEventLoop in the draft). Thus forcing you to use a delay attribute.
>>>>
>>>> <state id=“foo”>
>>>>   <invoke type=“something” id=“something” />
>>>>   <onentry>
>>>>     <!— this will fail as the invoker does not yet exist -->
>>>>     <send target=“#_something” event=“do.something” />
>>>>
>>>>     <!— this will work as we had an empty internal queue -->
>>>>     <send target=“#_something” event=“do.something” delay=“1ms" />
>>>>   </onentry>
>>>> </state>
>>>>
>>>> Is anyone else bugged by this behavior and resorted to the delayed send idiom, is there something more straight-forward or did we misinterpret the SCXML draft at some point?
>>>>
>>>> If this is indeed correct behavior, maybe we could specify that an invoker *must* raise some internal event after being successfully invoked?
>>> I think that is the correct behavior. And that delays are a bad way to handle it. In many situations, a 1ms delay would be enough. In some,  however, even 1s may not allow the interpreter to get to the point where the invocation is ready (because, yes, it should always have *started invoking* after the 1ms delay but there is no guarantee that the invocation is ready to queue events).
>>>
>>> Besides, if you want to send instructions to an invoked session as soon as it starts, why not use the <invoke> parameters instead?
>>>
>>> I agree that an event to indicate the invoked session is ready could be handy, and would be very easy to implement so why not.
>>>
>>> BTW, it is my understanding that in the example you give, the second <send> wouldn't even be evaluated since the first error would crash the <onentry> block. Right? Or does the error.communication occur asynchronously even for non-delayed sends with an invalid target?
>>>
>>> 			David
>>
>> -- 
>> Jim Barnett
>> Genesys
>

-- 
Jim Barnett
Genesys