2

Assume there is asio's deadline_timer or similar, it expires and the callback is invoked. During the invocation and while the callback is still running the cancel is called. The question is the cancel gonna block until the callback finishes?

kreuzerkrieg
  • 3,009
  • 3
  • 28
  • 59
  • That's a very good question. I think that `cancel` has been deprecated for a reason. And a reason would be canceling any async operation without blocking and waiting the callback, which in addition led to an unexpected behaviour. Even their [documentation](https://www.boost.org/doc/libs/1_67_0/doc/html/boost_asio/reference/basic_waitable_timer/cancel.html) suggests using non-error code overload. But I'm not 100% sure. – mutantkeyboard Jun 26 '18 at 11:43
  • 1
    just checked a second ago, it is not blocking, so your callback would wreak havok on stuff you try to execute. And BTW, I'm using the non-ec overload... Thats quite disappointing since I have to (for reasons too long to explain) wait on timer destruction to block until there is no operations in flight, neither scheduled nor already executing – kreuzerkrieg Jun 26 '18 at 11:56
  • `deadline_timer` is not thread-safe, so calling `cancel` concurrently is UB. Or do you mean some other scenario? – Igor R. Jun 26 '18 at 18:48
  • @IgorR. any link to support your claim? consider following scenario, you have `basic_waitable_timer`. you set timeout, by using `spawn`, `wait` asynchronously and then, even from the same thread you call `cancel` sounds legit for me – kreuzerkrieg Jun 26 '18 at 20:45

1 Answers1

1

No, cancel doesn't block and also doesn't wait for any handlers to have completed.

It is your responsibility to synchronize access to the timer instance if access is from different threads.

The limited threadsafety is documented here: https://www.boost.org/doc/libs/1_67_0/doc/html/boost_asio/reference/basic_waitable_timer.html#boost_asio.reference.basic_waitable_timer.thread_safety

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Just to make it clear, If one thread calls `expires_after` and another calls `clear` both should be performed under lock? – kreuzerkrieg Jun 27 '18 at 04:41