async keyword and choice of the TaskScheduler

Question

I would like to know the reasoning behind the way the compiler choose the TaskScheduler when compiling using the async keyword.

My test method is called by SignalR (

Answer 1

When you call:

private async void SendUpdates()

With the call to Task.Run and using the async keyword on the anonymous delegate, you aren't actually providing a continuation; you start the Task, and you're giving the Run method a continuation, which it then processes. That continuation is not channeled back in any meaningful to the code that called Task.Run.

This is why you get the exception, the handler doesn't know to await on the Task that the call to Task.Run produces.

That said:

private void SendUpdates()

Works because the task is created and the code doesn't capture a SynchronizationContext (because there is no async keyword on the method, Task instances don't capture it by default). You are firing the task, but it's fire-and-forget.

And the following works too:

private async Task SendUpdates()

Namely because in returning the Task, you've returned an awaitable that the callback can work with.

To answer your question directly, the compiler will make sure to get the SynchronizationContext returned from SynchronizationContext.Current before you call await; whatever continuation is called after the awaitable returns will be called using that SynchronizationContext.