Re: [SCXML] Execution order of onexit and cancelInvoke

I disagree.  The spec does not say that cancelInvoke (or invoke, for 
that matter) is blocking (or non-blocking).   The spec describes what 
must happen in the invoking session, and what must happen in the invoked 
session, but it doesn't try to synchronize those two sequences of 
events.   We were pretty careful _not_ to say certain things to avoid 
constraining implementations.  Exactly how cancelInvoke works on a given 
platform is up to the application, as are the details of the timing 
between the invoking and invoked process.

Another way of phrasing things is that <invoke> is not intended to 
produce tightly co-ordinated processes.  If you want to be sure that the 
file is closed when you exit the state, it's best to use custom 
executable content (for which the platform can define the timing as 
tightly as it wants) or maybe <send> to an external entity and then wait 
for a response.

- Jim

P.S.   The following phrase makes it pretty clear that we are not making 
assumptions about timing.  "Once it cancels the invoked session, the 
Processor MUST ignore any events it receives from that session."  If the 
cancelling action were blocking, couldn't we be sure that we wouldn't 
receive any further events from the invoked process?


On 9/11/2017 4:41 PM, panic wrote:
> Hi Jim,
>
> Jim Barnett:
>> The definition is what the group intended.   The idea was that the
>> invoked process is  independent of the invoking process, and you
>> shouldn't assume any synchronization among actions in the two states.
>> Cancelling the invoked process as the first on-exit handler would imply
>> a degree of synchronization that we wished to avoid.  For example, you
>> cannot make any assumptions about how long it will take the invoked
>> process to terminate, so it would not be safe to assume that the invoked
>> process had terminated when the first (or even the last) on-exit handler
>> executed.
> Thanks for the explanation. I understand, however, that there actually
> is synchronzation: after the onexit handlers are executed, the
> cancelInvoke step is run, and here the state machine waits for the
> invoke to terminate.
> If this did not block, then it might be that the file is opened for
> reading/writing/seek in an <invoke> session in the next state while the
> first invoke session is still writing (or flushing) it. So it must block
> until the session terminated (-> synchronization), otherwise one would
> get all sorts of weird races and conditions.
>
>> The problem with your example is that it assumes such a synchronization.
>> It would be much safer to have the invoked process open and close the
>> file by itself.
> Also if the invoked session is in itself an SCXML state machine, it
> synchronizes already on the onexit handlers. Why treating a
> (independent, detached) SCXML state machine differently than, e.g. a
> thread. For the invoked state machine you also cannot assume how long it
> takes to terminate (execute all onexit handlers) of the invoked session.
>
>> 6.4.3 Implementation of <invoke>> [...T]he following requirements hold in the case where the invoked
> process is itself an SCXML session:
> ...
>> o As described above, if the invoking state machine exits the state containing the invocation [...], it cancels the invoked session. The method for doing this is platform-specific. However, when it is cancelled, the invoked session MUST exit at the end of the next microstep. The Processor MUST execute the <onexit> handlers for all active states in the invoked session, but it MUST NOT generate the done.invoke.id event. Once it cancels the invoked session, the Processor MUST ignore any events it receives from that session. In particular it MUST NOT not insert them into the external event queue of the invoking session.
> Compared to an invoked state machine, an invoked thread (or child
> process, ...) could be seen as a state with a default onexit handler
> that basically does a pthread_join.
> Why treating a non-state machine differently than state machine?
>
> Cheers,
>    panic
>

Received on Monday, 11 September 2017 21:17:33 UTC