Closed rgarrison12345 closed 5 years ago
That was by design, actually. Deep inside the parser logic, I am using a TextReader
and the ReadBlockAsync
method, which does not accept a CancellationToken
. So, even if I did encounter a cancelled token, I would just be checking after an async call completed anyway. It's more efficient to simple bubble back the latest, parsed record than constantly checking if the token has been cancelled.
You'll also notice I do not expose a ReadAllAsync
method. You really can't get a collection of results asynchronously today. When async enumerables are available, I will provide such methods with cancellation tokens.
The other thing to point out is the .NET framework has several APIs that do not accept cancellation tokens either. In many cases there's just not a decent solution to cancelling a request. I am usually surprised when this happens, too, so I know where you're coming from. I'll be curious if/when I switch to pipelines if there will be CancellationToken
parameters.
Keeping inline with other frameworks and .net libraries that offer async functionality. I think it would be beneficial to add in overload functions to all async methods to take in a cancellation token. Useful for when a long running operation takes too long or we no longer need the results of the asynchronous method so that we can cancel the execution of said method.