Re: Invoking on stable configuration but sending on entry

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

Received on Monday, 20 January 2014 13:24:33 UTC