Re: [asio-users] deadline_timer or handler_storage with handler_storage_service

[Marat A. <ab...@ma...>]

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