Hi Christophe, Thanks you for your reply. On Wed, May 30, 2012 at 5:17 AM, Christophe Henry <christophe.j.henry@googlemail.com> 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
