CancellationToken: Make it possible to provide a way to tell whether the cancellation came from a timeout or due to being 'manually' cancelled

[ksidirop-laerdal]

Currently there is no way to tell why a cancellation-token requested a cancel from the exceptions it throws. I guess it's too late to change the behavior of it in methods like .WaitAsync() to have it throw a TimeoutException.

If it's not too much of a hassle would it be possible to introduce a new property ala

CancellationToken.IsCancellationRequestedDueToTimeout

or something to that effect to help out when we need to figure out the cause?

PS: I'm aware of the technique that gets thing to work at the caller's level using linked-tokens and I do use it but it has a fundamental drawback on a different department:

If you try to develop a generic library that aspires to handle timeouts on tasks in an agnostic manner then you don't have access to the source-token(s) - you only have access to the single token being passed down to your method as a parameter and it doesn't make sense to support passing down 2 tokens as parameters just to cater to the 2-source-tokens-workaround (the API surface of the library would look ... baroque to say the least)

This is the motivation behind this feature request.

[timcassell]

#109246

[ksidirop-laerdal]

Unfortunately the feature request in question has a considerably wider and different scope. While this one here is simple, straightforward and to the point. I had a look at the way the timer is implemented inside the CancellationTokenSource and the scenario in which we have a timeout is fairly easy to spot so advertising the cause of the cancellation should be possible with just a few additions to the current implementation.

[colejohnson66]

You can work around this using multiple CancellationTokenSource objects; One on a timer and one for manual cancellations. Then, link them to get a single CancellationToken:

CTS a = new CTS(TimeSpan.FromX(1234)); // for a timer
CTS b = new CTS();                     // for manual cancellations

using CTS linked = CTS.CreateLinkedCToken(a.Token, b.Token); // don't ever touch this one
CToken token = linked.Token; // use this one in your code

Then, only manually cancel b, never a. If token signals a cancellation, you can check a.IsCancellationRequested and b.IsCancellationRequested to determine which one actually signaled. There is a slight race condition there if both CTSs signal before you check, but it's the best you can get with the current system.

[colejohnson66]

It's the linked token.

I've had to use code like this before. OCEx.CToken contains the one that caused the exception (technically, the one passed to its constructor), not any of the parent signals. If you pass the linked token around, OCEx.CToken will be that linked token. Specifically, token.ThrowIfCancellationRequested makes no consideration for it being a linked token — it just packs itself into an OCEx and throws it. Even if it did tell you, it doesn't help once code you don't control does if (token.IsCancellationRequested) throw new OCEx(); (without passing in the token).

Due to the race condition, you need to decide which token takes priority in your handler (should both signal).

One could probably do some trickery with a custom derived CTS type using manual cancellation token registrations and Interlocked.CompareExchange, but it's not anything I've done.

[timcassell]

Makes sense. That property seems not very useful, then.

[colejohnson66]

If you fully control the code, it has its uses. I also think the runtime passes in the token whenever it throws, but any 3rd party code is iffy.

[ksidirop-laerdal]

You can work around this using multiple CancellationTokenSource objects; One on a timer and one for manual cancellations. Then, link them to get a single CancellationToken:

CTS a = new CTS(TimeSpan.FromX(1234)); // for a timer
CTS b = new CTS();                     // for manual cancellations

using CTS linked = CTS.CreateLinkedCToken(a.Token, b.Token); // don't ever touch this one
CToken token = linked.Token; // use this one in your code

Then, only manually cancel b, never a. If token signals a cancellation, you can check a.IsCancellationRequested and b.IsCancellationRequested to determine which one actually signaled. There is a slight race condition there if both CTSs signal before you check, but it's the best you can get with the current system.

I'm aware of this technique and I do use it but as already mentioned it has a fundamental drawback:

If you develop a generic library that tries to handle timeouts on tasks in an agnostic manner then you don't have access to the source-token - you only have access to the single token being passed down to your method as a parameter (it would be baroque to force the users of the library to pass both their token and a custom-evaluation-callback that will report whether the cancelation token fired due to manual cancellation or due to a timeout.)

This is the motivation behind this feature request.

[timcassell]

Well now I'm curious, what is the actual purpose of wanting to know whether your caller canceled manually or from timeout? I would think that you shouldn't care. If you need to expose separate cancelation and timeout behavior, why not just accept a separate TimeSpan timeout parameter?