Re: [boost] [msm] orthogonal region and event consume

Subject: Re: [boost] [msm] orthogonal region and event consume
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2012-05-29 16:17:23

Hi Takatoshi,

> Hello Christophe,
>
> I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior.
> See the attached diagram and code. When Event1 occurs in State1,
> Action1 is invoked.
>
> I think the event isn't consumed correctly.

This is actually the desired behavior. It is also documented, but it's easy 
to miss it, the doc is getting quite big.
See: 
http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e852
"both transitions must be triggered by the same event".

> If the transition from State1 to State2 connect State2 directly
> instead of Entry1, the event seems to be consumed.
>
> What do you think?

This is coherent with MSM's style. A pseudo entry is defined as a connection 
between a transition outside the submachine and a transition inside. 
Logically, to process the inside transition, MSM will need to call 
process_event(Event1), thus triggering Action1 too. Another behavior would 
be surprising because it is also mandated that every region gets a chance to 
process any event processed on a submachine. Forbidding this would be 
nonstandard, wouldn't it?

Another standard-conform solution would be to mandate that, none would be 
the only acceptable event in the transition outgoing from the pseudo entry 
and this would be pretty sad because:
- it would break a lot of code
- Event1's data would be lost

I read your ticket. Note that it's not UML-conform to have 2 transitions 
originating from Entry1 (11-08-06.pdf §15.3.8 page 551).
After reading the Standard again twice, I realized that no example provided 
there displays any event on both transitions, which is really bad if it's 
what they mean. I need to have a look at other literature.

Concretely, what is the problem you're having so I can see what can be done?
IIUC yur patch consists of "cheating" with the queue but it has 2 
disadvantages:
- it costs run-time (ouch!)
- I bet there are cases where the queue is not in the state you'd want.

I suppose it would be possible to treat none on the outgoing transition with 
a special behavior but I need to be convinced it's worth the pain and 
compile-time. What is your use case?

> Thanks,
> Takatoshi
>

Regards,
Christophe