Async Functions with overload CancellationToken passed?

[TWhidden]

Any chance a future version will be able to take a CancellationToken on the Async ops? This way if a user is waiting on an operation, and they want to cancel it, it will stop it? I know it returns a Task on those functions, and you are leaning on the .Result for many of the functions. This way you can pass the token all the way down the stack. Following your source, it seems like it could be easily passed. You could add the optional param.

I know this is opensource, so I guess I could add it if desired. What is your thought on that?

Cool Lib BTW.

[TWhidden]

Mock Up example:

` try
{
var client = new TMDbClient(Settings.Default.TMDbApiKey);
var token = await client.AuthenticationRequestAutenticationTokenAsync(taskCancelationTokenSource.Token);
}
catch(TaskCanceledException t)
{
// Ignore, Task was canceled.
}
catch(Exception ex)
{

        }`

[Naliath]

What would you expect on cancelation? The only place we really wait is when we call the actual api so I guess a cancelation could ignore the result. I figure it would be easier to just kill the taks in the consuming application, that would have an immediate result

[LordMike]

In principle we should pass it on to HttpClient. It will then be able to cancel the network stuff, rather than just having it spew thread aborts or similar.

[LordMike]

It would allow us to have timeouts out of the box, but just passing a TaskCancellationSource with a cancelafter... :)

[Naliath]

Should not be too hard, just a bunch of overload to add

[LordMike]

Yea. I've begun work on it.

[TWhidden]

Sweet. Yea, you can pass that token all the way to the HttpClient. Let the caller handle the TaskCanceledException. One of my fav parts of the Task Library.

[TWhidden]

public Task MyMethod(CancellationToken t = default(CancellationToken))
{
return Task.FromResult(0);
}

Use that on all your normal calls. no need to create new methods. The compiler will handle creating the overloads for you.

[TWhidden]

@LordMike -- Totally forgot about the extra benefit of the timeout. Yes, that will keep a UI from waiting for some other timeout within the API (bad internet connection, bad dns, etc).