[asio]How to insure async handles not be called after calling deadline_timer::cancel()?
The document says, If the timer has already expired when cancel() is called, then the handlers for asynchronous wait operations will: have already been invoked; or have been queued for invocation in the near future. These handlers can no longer be cancelled, and therefore are passed an error code that indicates the successful completion of the wait operation. Does this mean that async handlers may be called after calling deadline_timer::cancel() (say, the second curcumstance) ? If yes, it seems make things unintuitive, eg. delete the resources that associate with handlers after cancel(). Is there any way to suppress or identify these handlers? thx.
Does this mean that async handlers may be called after calling deadline_timer::cancel()
Yes.
If yes, it seems make things unintuitive, eg. delete the resources that associate with handlers after cancel().
Don't delete these resources, bind them to a shared_ptr and they will be released automatically after the handler invocation is complete.
On 10/12/2010 12:19 AM, 鑫炜廖 wrote:
The document says,
If the timer has already expired when cancel() is called, then the handlers for asynchronous wait operations will:
have already been invoked; or have been queued for invocation in the near future.
These handlers can no longer be cancelled, and therefore are passed an error code that indicates the successful completion of the wait operation.
Does this mean that async handlers may be called after calling deadline_timer::cancel() (say, the second curcumstance) ? If yes, it seems make things unintuitive, eg. delete the resources that associate with handlers after cancel(). Is there any way to suppress or identify these handlers?
thx. _______________________________________________
This is true for all handlers after an canceled async operation. Your best course of action is to use shared_ptr and bind for handlers. In particular, the normal pattern is to use shared_from_this with bind. The result is lifetime management based on handler usage so you will be "safe". You can find examples of this pattern as well as a "description" of the proactor model in the ASIO boostcon slides found here: <http://www.objectmodelingdesigns.com/boostcon10/> michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
participants (4)
-
Igor R -
Michael Caisse -
鑫炜廖