Page 1 of 1

Is the event processing re-entrant?

Posted: 23 Jan 2017, 11:27
by kamrann
I often find that within a behavior handler I need to fire off a new event, to be handled by some other part of my state machine (which is constructed from multiple encapsulated submachine classes, which I reuse).
Currently I simply store a reference to the top level state machine within my submachine class, and call fire_event as needed. I've not run into any issues from doing this so far, but I wonder if it's supported? Sometimes I noticed some slightly unexpected ordering in the log output, which I am guessing may imply doing this results in recursive processing.

If this approach goes against intended UML statechart use and I should be going about things differently, I'd be interested to know.

One reference that may be of relevance - I believe boost:statechart makes use of an event queue which can be posted to from within a handler, and the processing mechanism simply repeats until the queue is empty, thereby avoiding any recursion.

Re: Is the event processing re-entrant?

Posted: 23 Jan 2017, 14:50
by Wolfgang Petroschka
I often find that within a behavior handler I need to fire off a new event, to be handled by some other part of my state machine (which is constructed from multiple encapsulated submachine classes, which I reuse).
Currently I simply store a reference to the top level state machine within my submachine class, and call fire_event as needed. I've not run into any issues from doing this so far, but I wonder if it's supported? Sometimes I noticed some slightly unexpected ordering in the log output, which I am guessing may imply doing this results in recursive processing.
It is currently supported for async_state_machines, but it is not supported for state_machines (the sync single threaded versions). The reason is that the async_state_machine uses a queue for events internally. These events are processed one by one in a dedicated thread. The state_machine on the other hand processes events directly. Thus firing an event inside another event handler causes a recursive call which can break stuff (e.g. when doing so in a enter behavior).
If this approach goes against intended UML statechart use and I should be going about things differently, I'd be interested to know.
No, it does not AFAIK and the limitation on the state_machine is, well, ugly. We will provide a fix for the in the next version of libyasmine.
One reference that may be of relevance - I believe boost:statechart makes use of an event queue which can be posted to from within a handler, and the processing mechanism simply repeats until the queue is empty, thereby avoiding any recursion.
I like the idea of having an interface available which you can use to fire events (safely) from within your handlers. It also will remove the burden of having to pass the state machine into your states or transitions. We'll add this together with the fix.

Re: Is the event processing re-entrant?

Posted: 20 Feb 2017, 07:40
by kamrann
I like the idea of having an interface available which you can use to fire events (safely) from within your handlers. It also will remove the burden of having to pass the state machine into your states or transitions. We'll add this together with the fix.
Yep, passing around a state machine pointer felt somewhat hacky but I found it necessary for what I needed to do. It would be great if that was no longer needed.

Re: Is the event processing re-entrant?

Posted: 24 Feb 2017, 09:55
by Wolfgang Petroschka
The feature will be part of the yasmine release 1.1.0 which is going to be available in the next couple of days!

Re: Is the event processing re-entrant?

Posted: 06 Mar 2017, 14:34
by Tibor Molnar
yasmine 1.1.0 was published today ( March 06, 2017) and contains the feature to fire events from a state or transition. An example of 'how to' can be found in the Event collector example.