Re: [SCXML] Execution order of onexit and cancelInvoke

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 20:42:03 UTC