Destroying state charts

[Ricardo Morais]

Hi, I have another question,

How can I revert a statechart to a previous snapshot? Is it possible to revert it or destroy it and start a new one?

Thanks,

Ricardo Morais.

[Jacob Beard]

Hi Ricardo,

The best practice approach is to create a new SCION interpreter instance using the previous snapshot. The API for that is:

    interpreter = new scxml.scion.Statechart(scjson, {snapshot : previousSnapshot});

Restoring a snapshot is designed to be an extremely cheap operation; and the SCION interpreter is not known to leak memory. Just follow best practices so that the previous SCION interpreter instance can be garbage collected by the js interpreter, i.e. do not reference it inside of a closure.

Thanks,

Jake

--
You received this message because you are subscribed to the Google Groups "scion-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scion-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ricardo Morais]

Hi again,

I'm concerned that the previous interpreter instance will continue to run parallel to the new instance. How do I make sure the previous instance has stopped completely? I want the previous instance to stop executing immediately. Is it possible for me to create e.g. a 'stop' method in my SCION fork that would stop the instance execution?

Thanks,

Ricardo Morais.

[Jacob Beard]

Hi Ricardo,

The gen method, which triggers a state machine big-step, is synchronous. After the call to gen completes, the state machine instance relinquishes the thread and does not do any work.

It’s possible that timers might have been scheduled during your call to gen, either through JavaScript’s setTimeout function, or using <send>/@delay, and so you will want a way to make sure that these delayed calls to gen do not trigger subsequent transitions. The best approach right now would be to use SCXML semantics, and create a final state, then create a top-level state with a transition that targets this final state. When the SCION instance is in a final state, it will not longer respond to events. You could also add onentry actions to the final state to clean up your timers using <cancel> and clearTimeout, respectively, if you want to, but I can only think of one edge case where this would be important: if you have triggered a setTimeout from within the state machine that has side effects on objects passed into the state machine from outside of the state machine. In that case, you would probably want to make sure you cancel the setTimeout, and you would need to handle this explicitly in your state machine code.

One consequence of this technique is that, when you transition from the current configuration to the final state, all of the exit actions of the states in the state machine's current configuration will be executed, which may be undesirable, particularly if your SCXML has exit actions which either: a) have side effects outside of the state machine (e.g. if the actions reference objects which have been passed into the state machine), or b) are computationally expensive. 

Please let me know if you can envision a scenario where a final state would not work, and a stop method on the state machine instance would be needed.

Thanks,

Jake

[Ricardo Morais]

Hi Jake,

The problem with the final state is that I would have to specify it for every SCXML file I make. This is undesirable since I will have no control over the files (they will be made by users will little to no knowledge and uploaded to my server).

Thanks again, 

Ricardo Morais. 

[Jacob Beard]

Hi Ricardo,

You could transform the user-submitted SCXML to wrap the user states in a parent state, and add the associated transition and final state.

Alternatively, could you please provide more information on when the user would want to “stop” the state machine instance, and what the expected behavior would be?

Thanks,

Jake

[Ricardo Morais]

Hi Jake,

I guess the wrapper would work. I can do some cleaning up in the transition to the final state. I will try that approach and come back to you. In the mean time if you are curious check my git repositories. https://github.com/moraispgsi/fsm-core, https://github.com/moraispgsi/fsm-engine, https://github.com/moraispgsi/fsm-engine-restfull, https://github.com/moraispgsi/fsm-engine-backoffice, https://github.com/moraispgsi/action-dispatcher.

Thanks for all your help, 

Ricardo Morais.