Re: [boost] [asio] timer questions

From: Andrew Schweitzer (a.schweitzer.grps_at_[hidden])
Date: 2005-12-28 16:47:00

Andrew Schweitzer wrote:
[snip]
> 
> Here's our use case: timer completions go to a queue (unlike asio which 
> fires them immediately). Once they are in the queue they can't be 
> canceled. So we had situations like this:
> 1) start timer 1.
> 2) timer 1 completes, goes to queue.
> 3) just at that instance, cancel timer 1.
> 4) start timer 2.
> 5) pop timer 1 from queue for processing. Now it's very nice to be able 
> to tell that it's timer 1 (to be ignored) and not timer 2 (to be handled).
> 
> On the surface at least, asio doesn't have this particular problem, 
> since timer's are not stuck in a queue. I think the problem arises in 
> our case because the handler can execute after the timer has been 
> canceled, whereas I think if I read the asio code correctly, cancel 
> either prevents the handler from ever executing (without the "aborted" 
> code) or if the execution is already in process waits for it to complete 
> via the wait for the select_reactor's mutex_. 

Oh... wait... the timer *is* queued, I think, in the IoCompletionPort 
queue... so it looks like in asio it would be possible to cancel the 
timer and still have the timer execute... right? If so is there anyway 
to detect this is happening (other than the bound arguments?)