Repository navigation
Futures should be individually cancellable #520
Description
Activity
I like the idea of using
Cancelledinstead ofInstanceDropped! Do you think we can just move forwards with this, and I'll start implementing it? Or did you want to wait and discuss?I think the rename of the enum could probably be fine without further discussion, but maybe whether we have
CancelFuturewe can wait and discuss since that would be non-breaking anyways?I agree, having a more generic name is better and we should just go ahead with it. Though I'd love if we had a word that didn't have ambiguous spelling.
Based on ngrams I'd probably choose
Cancelleddespite many claims thatCanceledis the American spelling (I don't think that's really true, ngrams shows it close to even).
https://books.google.com/ngrams/graph?content=canceled%2Ccancelled&year_start=1800&year_end=2022&corpus=en&smoothing=3&case_insensitive=falseStrong +1 on this proposal.
Mar 20 meeting:
- KN: Cleanup a future without dropping the whole instance.
- CF: Don't understand why the described RAII wrapper should work like that. This would cause the callback to be called in the destructor. Possibly dangerous if using exceptions.
- LK: TBH don't understand either.
- CF: Seems like improper usage of the API. [Don't see when you would actually need to do this.]
- …
- KN: Wouldn't be able to really cancel all operations. Just cancel the callback, let the work finish in the background. Some concern that if WaitAny is happening on another thread, won't always be able to interrupt it. We'd call the callback immediately on cancel, but WaitAny would keep going and not call the callback.
- (EDIT: This is not a concern with instance drop because you can't drop the last external ref to the instance while any thread is inside instance->WaitAny)
- …
- LK: We could add this after V1.
- KN/LK: We'll need to investigate if it's possible to refactor this RAII wrapper thing so it either ASSERTs it's already complete in the destructor, or uses refcounting or weakref to make it so it's OK for the callback to be called later after the application drops its own ref to the RAII wrapper.
- KN: Still feel like since dropping the instance can cancel futures, there should be a way to cancel them individually, but I don't have a specific use case for it.
- KN: OK to rename InstanceDropped statuses to Cancelled?
- CF: Sure.
Sounds good especially since we can non-breaking add it postv1
Futures can currently be cancelled only by dropping the instance. It would be useful to be able cancel them individually.
As an example, if you write a C++ RAII wrapper around a
WGPUFuture(say,myapp::WebGPUFuture<wgpu::ComputePipeline>) and you drop it, there's no way to ensure the callback gets called except to wait for the future. If we had a way to cancel futures likevoid wgpuInstanceCancelFuture(WGPUFuture)1, you could do that instead - basically, call the callback immediately and ignore/abort any ongoing work.Right now we already have the
InstanceDroppedstatus, I think we could genericize this toCanceled/Cancelled2 and use it for this too.Footnotes
This function could have a return value indicating whether it actually got canceled, though it seems probably not necessary because you'll get the status via the callback. ↩
though I dislike this word because its spelling is ambiguous, similar to adapter vs adaptor ↩