![](https://secure.gravatar.com/avatar/1e08aa739f83c3dd1f50c9f9fb10a4f4.jpg?s=120&d=mm&r=g)
Hi Jarl
Can anyone tell me how to query a state on an asynchronous_state_machine?
The obvious answer would be to say use the state_downcast method (which is inherited from state_machine. But in practise it seems harder than so.
But opposed to state_machine, when using asynchronous_state_machine the instance is not created explicitely, it is created implicitely by the scheduler, like this: myMachine = myEventHandler.create_processor<AsyncMachine>(); , hence there is no handle to the state machine itself. All I have is a handle to the processor (sc::fifo_scheduler<>::processor_handle ).
This is intentional. If fifo_scheduler supported a state_downcast method then inevitably race-conditions would arise (the result of a state_downcast is a state object, which could have been destructed long before the caller gets hold of it).
So is there a way to come from sc::fifo_scheduler<>::processor_handle to AsyncMachine (which inherits sc:asynchronous_state_machine)?
No, for the same reasons. A sc:asynchronous_state_machine<> subtype is serviced by the fifo_scheduler thread. Directly accessing it from a different thread would again open the door to race-conditions or dead-locks. The proper way to query an asynchronous state machine is by sending it a special event carrying a boost::function object. The state_machine typically defines an in_state_reaction for said event, which simply calls boost::function::operator(). This arrangement lets you execute arbitrary external code in an FSM. Of course, if said external code needs to send results to another thread, then you'd need to employ a condition variable or some such and make sure that you make copies of all heap-allocated data that you hand over. This whole procedure could be implemented nicely with futures, but Boost does not (yet) sport such a library :-/. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.