Re: [Boost-users] [Statechart] Question regarding state_machine eventhandling

Subject: Re: [Boost-users] [Statechart] Question regarding state_machine eventhandling
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2010-02-25 17:54:38

Hi Arne

> For various reasons I do not want to use the asynchroneous_state_machine - 
> mostly because my application is built around a global event/message 
> handler and I do not want to use multiple threads with their necessary 
> synchronization.

As Igor has already pointed out, you don't have to use multiple threads. In 
fact, it's perfectly sensible to use multiple asynchronous_state_machine<> 
subclass objects hosted in one fifo_scheduler in a program that only has 
exactly one thread. Moreover, even under circumstances where you have very 
limited control over a global message queue and its handlers, you should 
still be able to use fifo_scheduler, as you can instruct it to simply return 
from its operator() as soon as its internal queue runs empty. So, in your 
scenario, if you can ensure that fifo_scheduler::operator() is called 
periodically, you *can* use async machines.

> It basically works because in my hierarchy 
> state_machine<>::process_event() is called only in one direction, while in 
> the "opposite" direction (or if unsure) state_machine<>::post_event() is 
> being used.
> E.g. A calls B->process_event(), B calls C->process_event(), but C calls 
> B->post_event() and B calls A->post_event().

state_machine<>::post_event() is not intended to be called from code 
"outside" of the machine, but only transition actions, which is why 
post_event is documented as being protected. Unfortunately, it is public in 
the code because it has to be called from other class templates and template 
friend support was very spotty at the time this was implemented. Anyway, I 
certainly could have done more to prevent calls from outside (e.g. with an 
assert and/or better documentation). May I ask you to enter a ticket for 
this?

Thanks & Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.