Re: [boost] [msm] Message queue and copy constructed events
Hi Richard,
I have that request as well to use the MSM without heap actually I have managed to compile MSM in an embedded target without stdlib, rtti, exception and no heap but only if queues are disabled.
Yes, message queue and deferred event queue.
In our system we never copy events and for us the best would be if you could just able to provide us a backend to use our own event queue implementation where we make sure that we use a queue form the RT scheduler where no copy operation is required.
I think it's two different issues. Having your own queue will save you the heap cost of the std::queue but not the copy, which is done by using boost::bind. Of course I could use ref/cref but there is no way for msm to know how long the event will still be around, unless we add the possibility for a user to tell msm that the event will be around long enough (using some typedef for example). This will, however, not remove completely the heap costs as the bind is then passed to a boost::function (to anonymize the event) => heap. Thus, just providing another container will not do the trick easily. What kind of container are you thinking about? Regards, Christophe
Hi Christophe Lets separate 2 thinks. 1: no heap operation this is a nice to have feature we can live with it. According my understanding the only place where heap is used is in the std:queue ? Am I correct ? If yes than if the user has a possibility to provide its own queue implementation than he/she can make sure about avoiding heap usage. 2: event copying. You saying copy is happening when bind is used to anonymize events to be able to store them in a queue. According my understanding of event driven systems we can say that as log an RTC step is not finished -> means that the most outer process_event does not retuned the event which was used in the call of the process_event should be valid. This means that events will be valid even with queuing for queues which are used during pseudo entry and exit because the processing of those events are always finished before the more outer process_event is returned. The only place where this is not true ->when the event should be available longer than the RTC step is when the event is deferred. So I think it would be enough for non deferred queues to internally before the bind store the event in a ref/cref and bind that and put to the queue -> no copy. For deferred queues there is 2 ways to go. First is to copy the event during bind or have a user implement a queue which interacts whit the underlaying zero copy scheduler. and only again store a ref/cref in a bind. maybe it is enough to have 2 callback to the user when an event is deferred and when it is recalled and not needed any more. It would be nice to have configuration possibility to use deferred queues with copying or with ref/cref and this 2 callback. Is feasible to implement such a feature ? Thanks a lot Br. Richie On 16 June 2010 23:32, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
Hi Richard,
I have that request as well to use the MSM without heap actually I have managed to compile MSM in an embedded target without stdlib, rtti, exception and no heap but only if queues are disabled.
Yes, message queue and deferred event queue.
In our system we never copy events and for us the best would be if you could just able to provide us a backend to use our own event queue implementation where we make sure that we use a queue form the RT scheduler where no copy operation is required.
I think it's two different issues. Having your own queue will save you the heap cost of the std::queue but not the copy, which is done by using boost::bind. Of course I could use ref/cref but there is no way for msm to know how long the event will still be around, unless we add the possibility for a user to tell msm that the event will be around long enough (using some typedef for example).
This will, however, not remove completely the heap costs as the bind is then passed to a boost::function (to anonymize the event) => heap. Thus, just providing another container will not do the trick easily. What kind of container are you thinking about?
Regards, Christophe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Christophe Henry -
Richard Szabo