From the comment:
There is nothing mentioned regarding asynchronous or synchronous code. Is WinRT code asynchronous by default or is there something else I don't know or don't understand?
There are at least two reasons for not blocking the client user interface (including WinRT):
- Avoid blocking the user interface and maintain it freely
- avoid the deadlocks described in Steven Cleary's blog when there is
await in the current call chain to the top stack of the frame;
The latter is especially important for WinRT, where asynchrony is common. The entire WinRT infrastructure was designed as "async all the way down" , so it is very likely that you will create a dead end if you use task.Wait or task.Result anywhere in the user interface stream.
There are also at least two reasons for an ASP.NET server application not to block:
- Lock
- makes your web application less scalable because a blocked stream may serve other incoming HTTP requests.
- same deadlock scenario.
You can view the list of links in the async-await wiki for further reading.
source share