[boost] Re: [prereview request][fsm]

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-23 14:06:42

"Andreas Huber" <ah2003_at_[hidden]> writes:

> Hi Dave,
>
> [snip]
>> After a brief glance, it looks like a very sophisticated and
>> well-thought-out library.
>
> Thanks :-)
>
>> I'd like to know if following state
>> transitions require dynamic allocation or not.
>
> By default (i.e. when you define states as demonstrated in the tutorial), a
> dynamic allocation happens in the course of every state entry. However,
> since users define all state classes themselves, they have full control over
> how each state will be allocated (see "Memory management customization" in
> the rationale).

OK, that's still dynamic allocation, but it may be good enough.

Also, do I note that there's always function pointer indirection for
event dispatch?  While you clearly need something like that if
there's an event queue, the MPL samples I posted earlier don't make
you pay for that in the cases where you don't need it.

> [snip]

>>> Out of the box, state_machine<> does the following:
>>>
>>> 1. The exception is caught
>>
>> By the state machine framework?
>
> Yes.

Clarification in the text would be good.

>>> 2. In the catch block, an exception_thrown event is allocated on the
>>>    stack
>>>
>>> 3. Also in the catch block, an immediate dispatch of the
>>>    exception_thrown event is attempted.
>>
>> Hum.  So basically, any throwing code that could be invoked from
>> processing exception_thrown and from processing some other event had
>> better be re-entrant?
>
> Yes. However, I don't think this will happen in practice. Code that is
> executed as a result of the processing of an exception_thrown event is
> typically very different from code that is executed during normal state
> machine operation. Moreover, if code reacting to an exception_thrown event
> throws itself an exception then this exception will under all circumstances
> be propagated to the state machine client. That is, error handling code does
> not have to be reentrant.

OK.

>>>    That is, possibly remaining events in the queue are dispatched
>>>    only after the exception has been handled successfully
>>
>> I don't understand the relationship here.
>
> A state machine can post internal events (simple_state<>::post_event())
> while processing an event. Those internal events are pushed into a queue and
> processed as soon as the state machine has finished processing the current
> event. If an exception is thrown while processing any of these events, the
> resulting exception_thrown event "overtakes" the still queued events.

OK.

>>> 4. If the exception was handled successfully
>>
>> What does that mean?  Who signals "successful handling", and how do
>> they do it?
>
> This is explained a bit further down under the title Successful exception
> handling. I agree that this is probably a bit hard to find. I've added a
> link in my version.

Thanks.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com