Re: [Boost-users] [statechart] process_event vs post_event confusion

Subject: Re: [Boost-users] [statechart] process_event vs post_event confusion
From: Dan Kelly (dkellyb717_at_[hidden])
Date: 2017-03-30 13:36:45

I can't speak for the author, but I have used statechart extensively over the years. Process_event and post_event operate fundamentally differently, and I don't think it is a good idea to mask the differences by forcing them into the same API. 

Think if process_event as synchronous event handling. (Do not confuse with asynchronous state machines.) The function call doesn't return until after event processing completes. If the state machine is not already in a stable state, there is no right answer to what this should do. 

On the other hand, post_event queues up the event for processing once any existing event processing completes. Hence, if called from the state machine while in an unstable state, the state machine will wait to be stable before invoking the event. But the actual function call returns immediately. 

The caller has to be aware of the differences. Upon return from calling post_event, event processing has not yet occurred. Upon return from process_event, it has. Theoretically you could get away with always calling post_event, but not the other way around. You have to be aware of which one you are calling. 

Dan Kelly
djkelly_at_[hidden]
[phone]

> On Mar 29, 2017, at 11:06, Robert Dailey via Boost-users <boost-users_at_[hidden]> wrote:
> 
> I'm seeing a usability issue between post_event and process_event.
> Basically, depending on where in the state itself I'm executing an
> event, I need to know which to invoke. My understanding is that if I'm
> calling within the context of the constructor of the state, I need to
> use post_event. Anywhere else (outside of construction, but still
> within a member function of the state subclass itself), you invoke
> "context<MyMachine>().process_event()".
> 
> Why can't post_event() automatically query the state machine to see if
> it is "busy" constructing a state, and if it isn't, forward the event
> to process_event() for me instead? Is there really a reason to have to
> make a logical decision between the two in code?
> 
> I'm using boost::statechart in my code at $DAYJOB and this is a
> reasonable complaint I get in my code reviews, especially from those
> not very familiar with boost itself. They have an expectation for the
> implementation of the state machine to be intuitive and easy to
> understand.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users