|
Boost : |
From: Chris Knight (cknite_at_[hidden])
Date: 2008-08-07 12:14:32
On Thursday 07 August 2008 10:58:21 am Andrey Semashev wrote:
> I see. However, tags are not a good candidate to dispatch events on
> since different events can have same tags. I think, the event itself
> should contain enough information to be dispatched after being postponed.
>
> BTW, you can achieve the same functionality right now if you bind the
> event to the process function of the FSM and save the call into
> boost::function.
I never thought of that one. Maybe a little mention in the Documentation would
be good. I imagine other potential users might want to do the same.
> I think, this would be an interesting feature to add in future releases.
> I won't be able to implement it before the review. State and transition
> base classes will have to be extended, in order to allow to postpone
> events. State machine and event classes will have to be modified too.
Yeah, something like EventID and TransactionID in each event and transaction
would be nice along with I imagine a deferred_state_machine and a
deferred_lock_state_machine
Thanks,
Chris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk