Open danburkert opened 1 year ago
Thank you for your suggestion, I was assuming a case like Go's context, where the parent's CancellationToken is passed to the child task when the task is generated internally. However, in the case of a simple API call, the library does not generate the task internally, so I would like to modify it so that unnecessary CancellationToken is not passed to the child task.
I'm not a Go expert, but I believe their async system works differently, and does require the child task to have an out-of-band explicit cancellation mechanism. Rust futures can be cancelled simply by dropping them. This is why e.g. tonic and reqwest don't have cancellation mechanisms built in.
When I added the pub/sub MessageStream
I hid the CancellationToken
within the struct, and cancel it when it is dropped. Then the user of the API doesn't have to think about it.
See https://github.com/yoshidan/google-cloud-rust/commit/423a559a288c1d7f306f275798a91a696763c58c
I see now that I could have stored a DropGuard
instead, then we wouldn't need to implement Drop
@fredr it's possible that cancellation doesn't need to be built in at all. If you have tasks communicating via channels, you can have task shutdown automatically when the remote end of the channel is closed.
Most of the client APIs appear to take an optional cancellation token. Tokio's
CancellationToken
type is designed to allow alerting a spawned task that cancellation is being requested. Becausegoogle-cloud-rust
isn't spawning tasks, it's not necessary for a cancellation mechanism to be built in to the library. Instead, users of the library can simply drop the futures returned from thegoogle-cloud-rust
APIs, perhaps in response to aCancellationToken
firing, to enable cancellation.