On 2/6/07, Elam Birnbaum (ebirnbau) <[EMAIL PROTECTED]> wrote: <snip/>
Ok, so let me see if I understand. You don't want to interrupt a state machine while it is working, but you don't really know when the state engine is working, which is why the concept of triggering events exists. The events are processed by the engine when it has time to do so. Now, the invoke, parentEvents, and cancel methods are all called by the state engine (and hence the thread that is executing the engine) and the engine blocks until these methods return. That means that when these methods themselves trigger events the state engine must handle them immediately and would essentially give priority to those events and not the events that the state engine has queued up. Not only that, but the state engine will not register the ending of a state and the entrance of another because it is handling the events in-line, which explains why I saw so many parentEvents method calls. That is why you want to be triggering events asynchronously, as evidenced by the SimpleSCXMLInvoker class in the Commons SCXML project, which triggers events in an asynchronous manner via the AsynchTrigger class.
<snap/> Mostly, yes. I'd add that its not the state machine engine (or any part of the Commons SCXML code) giving priority to events triggered synchronously within callbacks. Its already a deadlock (while it may not manifest as such immediately), and also an attempt to short-circuit any external event queues that the application may have set up.
Normally I would think that you would want the state engine to stop while the invoke process is running because that is what the state engine should be doing at the time
<snip/> Sure, thats when the state machine "comes to rest". More often than not, the time a state machine instance is processing events is going to be a (small) fraction of its total lifetime.
and the next state to visit will be determined by the events triggered by the invoke. Any parallel states would already be working in separate threads, so blocking in the invoke should not cause parallel states to block. So the only reason I can see for not wanting the invoke (and other methods) to take more than a trivial amount of time is because the state engine could have events waiting on it that would be prevented from being handled until the invoke method returned. The only event I could think of that would be triggered while the invoke method is being processed is the cancel event, which you would want to actually stop the invoke process. Are there any others?
<snap/> Any application defined events (having parallel invoked processes, sooner or later one will need some sort of IPC).
A couple of final notes. Since I was seeing this issue because I was not triggering events in separate threads, I would recommend that Commons SCXML either improve how events are triggered or update the documentation regarding invoke to point out that fact as it is not readily apparent.
<snip/> Or both, atleast the docs, i.e. we need a section in the user guide [1] devoted to invoke. If you want to write up some of your observations, either via the site sources [2] or the wiki [3], that'd be great too.
It would be great if the Commons SCXML SCXMLExecutor.triggerEvent and triggerEvents methods automatically spawned threads to actually trigger the events so that users won't have to worry about doing it themselves. To add flexibility, perhaps a setting in the SCXMLExecutor class could be exposed so the user can turn on or off whether events are triggered in separate threads.
<snap/> Correct, its a trade-off between complexity in the library (and some may say code smell with boolean flags) and developer discipline. We definitely do not want to spawn threads without an option not to (when it is deemed unnecessary, or inappropriate). Could be mitigated by documentation.
I will look to see if Jira has an option for feature requests so I can put that in.
<snip/> Sure, when you try to create a new issue, you can label it as a "Bug" or "Improvement" or "Task" etc. (I think there are a couple of others). -Rahul [1] http://jakarta.apache.org/commons/scxml/guide.html [2] http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/xdocs/ [3] http://wiki.apache.org/jakarta-commons/SCXML
Thanks again, Elam Birnbaum
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
