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 10:03:45

Hello,

I think that I found the solution.
So, I summarize the problem and solution into trac ticket.
https://svn.boost.org/trac/boost/ticket/6951

Thanks,
Takatoshi

On Tue, May 29, 2012 at 1:47 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
> I had gotten an incoming event confused with an outgoing event of
> entry pseudo state.
> Please ignore my patch.
>
> Regards,
> Takatoshi
>
> On Sat, May 26, 2012 at 11:43 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
>> Hello,
>>
>> I wrote a patch.
>> If an event that corresponds to the transition from an entry pseudo
>> state is not equal to boost::msm::front::none,
>> then do self->process_event(evt.m_event);
>> Else doesn't do it.
>>
>> This patch brings dependency that from msm::back to msm::front. If it
>> is not suitable, msm::front::none may move to msm/common.hpp.
>>
>> Thanks,
>> Takatoshi
>>
>> On Sat, May 26, 2012 at 3:40 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
>>> I analyzed this problem deeply. It doesn't relate to orthogonal regions.
>>> My understanding is that Boost.Msm requires the same event for
>>> transitions that to entry pseudo state and from entry pseudo state.
>>> So,  in simple_entry.png(attached diagram), the transition from Entry1
>>> requires Event1.
>>>
>>> But this requirement is sometimes problematic. Because submachines
>>> sometimes shouldn't know the outside information such as Event1. So, I
>>> chose msm::front::none instead of Event1 (entry_pseudo_event.cpp).
>>>
>>> msm::front::none event approach has two problems. One is preserving
>>> outer event. And then the event is handled similar as the deferred
>>> event. The other is there is no way to get the outer event in the
>>> submachine.
>>>
>>> I believe that the former should be fixed. But I found another solution.
>>> See the entry_pseudo_event_template.cpp.
>>>
>>> The event that corresponds to the transition from the entry pseudo
>>> state is injected as a template parameter. So, submachine doesn't need
>>> to know the Event1.
>>> This approach solves the both above problems.
>>>
>>> Thanks,
>>> Takatoshi
>>>
>>> On Fri, May 25, 2012 at 5:48 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
>>>> 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.
>>>>
>>>> If the transition from State1 to State2 connect State2 directly
>>>> instead of Entry1, the event seems to be consumed.
>>>>
>>>> What do you think?
>>>>
>>>> Thanks,
>>>> Takatoshi