You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Safe by default means that cancellation only occurs if the context is in an acceptable state to be cancelled. For example, blocked by I/O and external are probably unacceptable to cancel because IO may be writing to a resource currently held by the coroutine frame. Destroying the frame but allowing that coroutine stack memory to be reused by other coroutine frames would be disastrous. Blocked by external would also be a lifetime violation because some external coroutine scheduler/executor is expected to resume our coroutine and if they do so and our frame has been destroyed, we'd get UB. Being blocked by nothing is the perfect time to be cancelled. Being blocked by time and sync are also acceptable to be cancelled.
Calling cancel() would cancel if the state is cancellable or simply return. To be assured that the cancellation went through, the is_cancelled() API can be called. We could also provide a sync_cancel(). A better name combo would be try_cancel(), which attempts to cancel the operation, and cancel(), which performs a synchronous operation of waiting until the coroutine is cancelled before returning.
Thinking it over, I like the combo of try_cancel() and is_cancelled(). I don't see a reason to provide a hard CPU bound polling cancel for a future as the time that the operation may be blocked for it unknown. Making it clear with the words "try" is important to convey to users that a cancellation may not be possible.
This goes for context as well. The only time cancellation will block is in the destruction of a future or context. In those scenarios, the users must pay for cancellation on their threads for lifetime safety reasons.
Activity
kammce commentedon Jan 14, 2026
Thinking it over, I like the combo of
try_cancel()andis_cancelled(). I don't see a reason to provide a hard CPU bound polling cancel for a future as the time that the operation may be blocked for it unknown. Making it clear with the words "try" is important to convey to users that a cancellation may not be possible.This goes for context as well. The only time cancellation will block is in the destruction of a future or context. In those scenarios, the users must pay for cancellation on their threads for lifetime safety reasons.
[-]Consider if `future::cancel` should be safe by default[/-][+]Migrate to `future::try_cancel`[/+][-]Migrate to `future::try_cancel`[/-][+]Implement cancellation in context & future<T>[/+]context::cancel()#53kammce commentedon Jan 17, 2026
Resolved in #56