You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by at...@apache.org on 2014/09/15 15:28:44 UTC
svn commit: r1625030 - /commons/proper/scxml/trunk/src/site/fml/faq.fml
Author: ate
Date: Mon Sep 15 13:28:43 2014
New Revision: 1625030
URL: http://svn.apache.org/r1625030
Log:
Update scmxl faq
Modified:
commons/proper/scxml/trunk/src/site/fml/faq.fml
Modified: commons/proper/scxml/trunk/src/site/fml/faq.fml
URL: http://svn.apache.org/viewvc/commons/proper/scxml/trunk/src/site/fml/faq.fml?rev=1625030&r1=1625029&r2=1625030&view=diff
==============================================================================
--- commons/proper/scxml/trunk/src/site/fml/faq.fml (original)
+++ commons/proper/scxml/trunk/src/site/fml/faq.fml Mon Sep 15 13:28:43 2014
@@ -143,10 +143,32 @@
Can multiple threads safely interact with an instance of SCXMLExecutor?
</question>
<answer>
- To a certain extent. Things such as firing events on a state machine or
- reseting it are threadsafe. The underlying state machine needs to
- model any race conditions correctly. You have to worry about
- synchronizing access to other bits if you need to.
+ <p>
+ To a certain extent. The execution of an SCXML state machine through an SCXMLExecutor instance may only be done,
+ as per the specification, sequentially.
+ </p>
+ <p>
+ Multiple threads may 'send' or 'register' new events on a state machine through its #addEvent methods, which
+ then will be processed sequentially by the SCXMLExecutor.
+ </p>
+ <p>
+ If such events are registered while the state machine is executing, these will processed automatically
+ before the state machine 'returns' in a stable state.
+ </p>
+ <p>
+ If such events are registered or added while the state machine is in a stable state, the SCXMLExecutor its
+ #triggerEvents method will have to be invoked for the state machine to proceed with processing these events.
+ </p>
+ <p>
+ The SCXMLExecutor methods themselves are not thread save, and thus it is the responsibility of the 'manager' of the
+ SCXMLExecutor, typically the thread creating and initializing the state machine to also execute the state machine
+ and check upon its state.
+ </p>
+ <p>
+ Other threads collaborating with the state machine however should refrain to only use the #addEvent methods, or
+ otherwise be (externally) coordinated such that only one thread at a time is triggering the execution of the state
+ machine.
+ </p>
</answer>
</faq>
@@ -155,7 +177,14 @@
Are SCXMLExecutor instances serializable?
</question>
<answer>
- Yes, as long as all associated user-defined content is too.
+ <p>
+ No, but the SCInstance of an SCXMLExecutor, which contains all the 'state' of the state machine including the SCXML
+ document itself, is serializable after detaching through its #detachInstance method as long as all associated
+ user-defined content is too.
+ </p>
+ <p>
+ A detached SCInstance can be re-attached to the SCXMLExecutor using its #attachInstance method.
+ </p>
</answer>
</faq>