[boost] [msm] Message queue and copy constructed events

Subject: [boost] [msm] Message queue and copy constructed events
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-06-15 09:55:51

Hi Michael,

>in case we use message queueing in our state machines (which we actually
>have to because otherwise the pseudo exit state behaviour will not work
>correctly) our events have to implement a copy constructor because there
>is a possibility that some of them are queued.

Actually for the pseudo exit states it's also so that the event from
the outgoing transition can be convertible from the event coming from
the inner transition.

>We do not want that events
>get copied because they are very big and it certainly decreases our
>performance.
>Could you not just store pointers to events so that the events do not get
>copy constructed again?
>Our understanding of the queuing implementation is that the event instance
>is valid as long as the outer most process_event() is not returned to the
>caller. In that case it is not a problem to just store those pointers.

I suppose you are still talking about the pseudo exit states. It's not
that simple because queuing can happen surprisingly fast. One could
decide to defer inside the action method of the transition exiting the
pseudo exit. It's a corner case, but I can imagine someone will one
day find a use of it, like for about every single feature I put inside
msm.

>We also could use shared pointers as events and so only the shared
>pointers get copy constructed. But this would mean that we have to put all
>our events into shared pointers which also decreases performance and it
>would look like strange passing shared pointer as reference to the
>process_event() method.
>
>Do you have another idea in order to overcome this?

Why not simply pimpl the big data from the event inside a shared_ptr
as event's attribute? Or more efficiently, as I understand your data
is useful only until the end of a process_event, keep a pointer to it,
for example something like:

{
   Data data;
   fsm.process_event(my_event(&data));
} // data is gone here

>At the moment, we can not think of a proper solution for deferred events.
>In that case there would be no other solution than copy deferred events.

I'd prefer to avoid confusing users by using different behaviors,
especially as the above solution seems pretty simple to implement.

>Anyway, we would like to have a mechanism in order to influence the queue
>implentation and change it to a user definied implementation.
>Would it be possible to pass the queue type as an optional template
>argument to the state machine?
>This would the make state machine even more flexible and one does not have
>to use std::queue.

I'm thinking about this because someone requested the possibility of
using no heap at all and providing a fixed-size array instead. It
seems a reasonable request.

Regards,
Christophe