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

Subject: Re: [boost] [msm] orthogonal region and event consume
From: Takatoshi Kondo (redboltz_at_[hidden])
Date: 2012-05-29 19:33:43

Hi Christophe,

Thanks you for your reply.

On Wed, May 30, 2012 at 5:17 AM, Christophe Henry
<christophe.j.henry_at_[hidden]> wrote:
> 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.

I read the section that you mentioned carefully. My interpretation of
UML specification is different from yours.
It's really difficult to explain my interpretation. So, I draw the
diagram. See the attached file.
Am I misunderstanding?

> 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.

Indeed. I agree that the solution that depends on the queue is not good.

> 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?

My goal is to improve sub-machines' re-usability. If we want to reuse
sub-machines in another state machines, sub-machines shouldn't know
the outside information.
See my second mail in this thread. My solution using templates
(entry_pseudo_event_template.cpp) requires the template parameters
same as the number of entry point pseudo states in sub-machine. It's
acceptable but if outgoing transition would be able to use none, I
would remove the template parameters.

In the above case, it is not required to support multiple incoming
transitions to one entry pseudo state. Because the instances of
sub-machine are different.

I don't have any practical use case that requires multiple incoming
transitions to one entry pseudo state for now.

Thanks,
Takatoshi

>> Thanks,
>> Takatoshi
>>
>
> Regards,
> Christophe
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost