Andreas Huber wrote:
David Greene wrote:
Moreover, how do I actually extract information from the state machine? Since fifo_scheduler<>::processor_handle is a weak_ptr<> I can't use it to query the state of the machine or extract any machine-specific information (such as elapsed time in the StopWatch example, if it were asynchronous).
The fact that it's a weak_ptr is an implementation detail. You don't need to know that as a user. Besides creation and destruction of FSMs, the fifo_scheduler interface only allows you to send events. So, the only means of data exchange is through callbacks and events (as outlined in the other post). It is not possible to access the state_machine subclass objects directly because that would mean accessing data shared between threads. This in turn would mean that every state_machine member function needs to be protected by mutexes, which is a recipe for disaster, in my experience.
I understand your reasoning, but it makes it _really_ difficult to incorporate Boost.Statechart into an existing application. I'd have to create all kinds of callbacks and special events just to get some state out of the machine and make decisions based on that information. It seems as though with asynchoronous machines, it's almost an all-or-nothing affair. Either everything interacts via Boost.Statechart objects or there is quite a bit of painful interface code to coax out information when needed to drive some other piece of the application. Hopefully I can get by with a synchronous state machine. It's a very tiny piece of my application but it is the most critical piece. Before it was lots of hand-written ugly code and I was hoping to formalize it with Boost.Statechart. I think I can but it's just turned out to be more challenging than I thought. I'm not meaning to bash your work. I think it's quite wonderful, actually. I'm just relating one user's experience and pointing out some things that might be interesting to discuss. -Dave