4 ms·

One mechanism that doesn't seem to be mentioned is the .net style "manual" cancellation where CancellationToken is passed around everywhere and manually checked

by fowl2 5y ago

One mechanism that doesn't seem to be mentioned is the .net style "manual" cancellation where CancellationToken is passed around everywhere and manually checked, often throwing an exception to early return. Pros are that it's very explicit - there are no unexpected places for the code "stop", which is useful if there are effects that aren't easily modeled RAII style. Cons are that it's very explicit, having to me manually passed around everywhere, with all the possibility of forgetting. I guess "panic on cancel" wouldn't be very popular :P and I have no idea if/how the cancellation token scheme allocates.

Joker_vD 5y ago
That's also the Go's style, isn't it? With concisely named "context.Context" (not to be confused with any other relevant context) being passed around everywhere?
- asdfasgasdgasdg 5y ago
  Yes, this is the same style as go. Fortunately you don't have to check the cancel token everywhere since clients can just proceed as if you had been cancelled (in well designed systems). You just need to check it before and during potentially expensive or long running operations (IO or expensive computation, basically).
yoshuaw 5y ago
> One mechanism that doesn't seem to be mentioned is the .net style "manual" cancellation where CancellationToken is passed around everywhere and manually checked, often throwing an exception to early return. The async-rs/stop-token [1] library does exactly this. This post is just the first in a series. In a follow-up post I'm planning to zoom in on the uses and design of cancellation tokens. [1]: https://github.com/async-rs/stop-token https://github.com/async-rs/stop-token
- fowl2 5y ago
  looking forward to it!
WorldMaker 5y ago
It's not entirely "manually" checked in .NET, it is also sometimes "panic on cancel" in that the most common "manual" "check" in .NET is a simple `cancellationToken.ThrowIfCancellationRequested()`. While it is great to implement high-level, intelligent cancellation, for the most part in .NET as long as you are passing the CancellationToken to enough low-level components you are increasingly more likely going to get a TaskCancelledException from your low-level components and maybe don't even need to wire high-level checks. (Depending on what your business logic is, and yes, the usefulness of unwinding effects at a high level such as carefully rolling back transactions or what not.) Also it's really interesting that the original F# approach to .NET Cancellation was to handle them automatically in async { } blocks, handling and for the most passing them automatically, and after a lot of usage patterns seen in the real world they decided that the overhead of all the automated checks wasn't worth it enough and the new in F# 10 task { } blocks follow the rest of .NET in preferring entirely manual CancellationTokens.

by fowl2 5y ago

Joker_vD 5y ago

That's also the Go's style, isn't it? With concisely named "context.Context" (not to be confused with any other relevant context) being passed around everywhere?

asdfasgasdgasdg 5y ago
Yes, this is the same style as go. Fortunately you don't have to check the cancel token everywhere since clients can just proceed as if you had been cancelled (in well designed systems). You just need to check it before and during potentially expensive or long running operations (IO or expensive computation, basically).

yoshuaw 5y ago

> One mechanism that doesn't seem to be mentioned is the .net style "manual" cancellation where CancellationToken is passed around everywhere and manually checked, often throwing an exception to early return. The async-rs/stop-token [1] library does exactly this. This post is just the first in a series. In a follow-up post I'm planning to zoom in on the uses and design of cancellation tokens. [1]: https://github.com/async-rs/stop-token https://github.com/async-rs/stop-token

fowl2 5y ago
looking forward to it!

WorldMaker 5y ago

It's not entirely "manually" checked in .NET, it is also sometimes "panic on cancel" in that the most common "manual" "check" in .NET is a simple `cancellationToken.ThrowIfCancellationRequested()`. While it is great to implement high-level, intelligent cancellation, for the most part in .NET as long as you are passing the CancellationToken to enough low-level components you are increasingly more likely going to get a TaskCancelledException from your low-level components and maybe don't even need to wire high-level checks. (Depending on what your business logic is, and yes, the usefulness of unwinding effects at a high level such as carefully rolling back transactions or what not.) Also it's really interesting that the original F# approach to .NET Cancellation was to handle them automatically in async { } blocks, handling and for the most passing them automatically, and after a lot of usage patterns seen in the real world they decided that the overhead of all the automated checks wasn't worth it enough and the new in F# 10 task { } blocks follow the rest of .NET in preferring entirely manual CancellationTokens.