Boost logo

Boost :

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.


>>> 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.


>>> 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.


Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at