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?)