SignalR and WinRT client: Don't call Wait() on

Question

I have a question regarding SignalR's official documentation - Hubs API Guide - .NET Client. In the section - How to establish a connection. It has been written the following thing:

The Start method executes asynchronously. To make sure that subsequent lines of code don't execute until after the connection is established, use await in an ASP.NET 4.5 asynchronous method or .Wait() in a synchronous method. Don't use .Wait() in a WinRT client.

Does anyone know what is the specific reason not to call Wait()? Also, does also this apply when I have a WinRT client where I have a call with hubProxy.Invoke() to the server?

Thank you for your help!

Answer 1

From the comment:

There is nothing mentioned in relation to asynchronous or synchronous code. Is the code WinRT asynchronous by default or there is something else that I don't know or don't understand?

In a client-side UI app (including WinRT), there're at least two reason to not block:

• avoid blocking the UI and keeping it fluent;
• avoid the deadlocks as described in Stephen Cleary's blog, for cases when there's an await in the current chain of calls, on the upper stack frame;

The latter is especially important for WinRT, where asynchrony is pervasive. The whole WinRT framework has been designed to be "async all the way down", so it's very likely you'd create a deadlock if you use task.Wait or task.Result anywhere on the UI thread.

For a server-side ASP.NET app, there're also at least two reasons to not block:

• blocking makes your web app less scalable, because the blocked thread could be serving other incoming HTTP requests.
• the same deadlock scenario.

You may want to go through the list of links in async-await wiki for further reading materials.