Re: [asio-users] deadline_timer or handler_storage with handler_storage_service
Brought to you by:
chris_kohlhoff
From: Marat A. <ab...@ma...> - 2009-07-27 09:01:48
|
Dear Chris, handler_storage methods isn't thread safe (like any asio io_object - socket, serial_port) - and it doesn't need thread-safety because of it will be serialized accessed only (as session class instances - notice, handler_storage is only for temporal "handler parking" at active object). As I mentioned - I need to specify some value to the storing handler at the operation completion - just before the handler will be posted, not when it was stored. 1) deadline_timer::async_wait - Ok, I can bind handler to something if need. 2) deadline_timer::expires_from_now(....) - how can I pass completion value to the handler here? Solution (with deadline_timer) 1) deadline_timer::async_wait - Ok, I wrap handler by active object's method with bound tuple<Handler>. 2) deadline_timer::expires_from_now(....) - I have to store "completion value" at active object's field. 3) wrapped handler execution - I extract completion value from the active object's field and make a postage of source handler bound with completion value. Total, I have 2 postages/dispatches vs 1 at handler_storage, and also I have "wrapped handler execution" inner state.... Of cause I can use smart pointer to completion value (and bind it to wrapped handler which won't be an active object's method now) - but then I need heap allocation at every async operation - this is the worst solution. I will be very glad to not use hand-made handler_storage at all. But its logic isn't provided by asio. Best regards, Marat. -----Original Message----- From: Christopher Kohlhoff [mailto:ch...@ko...] Sent: Monday, July 27, 2009 11:59 AM To: asi...@li... Subject: Re: [asio-users] deadline_timer or handler_storage with handler_storage_service On Wed, 22 Jul 2009 21:28 +0400, "Marat Abrarov" <ab...@ma...> wrote: > Hi, Chris. > > Again. "handler B's chain of operations" doesn't make a direct call of > handler A (we are "in strand" - so we have to not stay at this strand > during > "out of object" operation - handler A execution) - it calls > handler_storage::post(argument_type arg) that makes the "postage" (to the > io_service reference given at handler_storage's constructor) of queued > handler binded with the given argument value to indicate the result of > operation completion. Ok, yes it's true: if handler A uses a different io_service::strand object to handler B, you should post (or really, just dispatch) across to the other strand when cancelling the timer. But don't you need to provide the same protection for your handler_storage? It doesn't appear (on a quick reading) to provide any thread safety on store() vs post() either. However, in my experience in using deadline_timer for exactly this purpose, they have all been on the one parent object anyway and so already sharing the same strand. In that case, no additional post is required. > With deadline_timer we can't set value of the queued handler's parameter > before it'll be posted. We can only post it (handler). You can pass an intermediate handler to the timer's async_wait, so I don't see the problem here. As I said earlier, I've used deadline_timer like this before without a generic wrapper around it. I'd like to put together a generic wrapper as an illustration of what I mean, but unfortunately don't have the time at the moment :( Cheers, Chris ---------------------------------------------------------------------------- -- _______________________________________________ asio-users mailing list asi...@li... https://lists.sourceforge.net/lists/listinfo/asio-users |