David Greene
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.
Multi-threaded programming is difficult ;-). Seriously, I'm aware that the asychronous_state_machine & scheduler combo has a very restrictive interface, which somewhat enforces the event-based programming rule that accessing shared state from different threads is best avoided.
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.
I do understand that there are scenarios where shared access is unavoidable, asynchronous_state_machine was simply not designed to support them. However, you can always use the thread-unsafe state_machine directly and appropriately protect it with mutextes.
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.
No bashing taken. Maybe I should have documented the fact that the asynchronous part of the library only exists because there's currently no library in Boost that supports multi-threaded event-based programming. As such it pursues (and always will be) a minimal approach. HTH & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.