Skip to main content

Avoid the use of task.Result

With the introduction of async/await, asynchronous programming in .NET  becomes a breeze. However with great power, comes great responsability.

I see a lot of programmers starting enthousiastic with the Task Parallel Library and the async/await syntax but a few days later, they start to report strange bugs and issues with their code(or even worse the end-user start to report this).

Almost all the time it is because developers didn’t fully understand what’s going on behind the scenes and when we dig into the code, there is almost all the time the following code(or similar):

var httpClient = new HttpClient();
var t = httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);
return t.ContinueWith(t1 => t1.Result.Content.Headers.ToString());

If you use the code above in a Console application, it should not be a problem. However if you try to do the same thing inside an ASP.NET(MVC) application you’re into trouble. Why? What makes this code different in ASP.NET vs a Console application. The answer is the SynchronizationContext. In ASP.NET, only one thread can handle a request at a time. You can do some parallel processing, but only one thread would have the request context. This is managed for you by the ASP.NET SynchronizationContext.

The moment a task attempts to resume within the ASP.NET request context when there is already a thread in that context, the thread will block and you’ll end in a deadlock situation. In the example above, the current thread will be blocked until the t1.Result is available. But t1 is waiting for the result of task t which will not be able to resume as the current thread is blocked.

How can we fix this?

Easiest solution is to correctly use the async/await syntax here and avoid the usage of the Task api’s:

var httpClient = new HttpClient();
var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);
return result.Content.Headers.ToString();

Some useful links:

Popular posts from this blog

DevToys–A swiss army knife for developers

As a developer there are a lot of small tasks you need to do as part of your coding, debugging and testing activities.  DevToys is an offline windows app that tries to help you with these tasks. Instead of using different websites you get a fully offline experience offering help for a large list of tasks. Many tools are available. Here is the current list: Converters JSON <> YAML Timestamp Number Base Cron Parser Encoders / Decoders HTML URL Base64 Text & Image GZip JWT Decoder Formatters JSON SQL XML Generators Hash (MD5, SHA1, SHA256, SHA512) UUID 1 and 4 Lorem Ipsum Checksum Text Escape / Unescape Inspector & Case Converter Regex Tester Text Comparer XML Validator Markdown Preview Graphic Color B

Help! I accidently enabled HSTS–on localhost

I ran into an issue after accidently enabling HSTS for a website on localhost. This was not an issue for the original website that was running in IIS and had a certificate configured. But when I tried to run an Angular app a little bit later on http://localhost:4200 the browser redirected me immediately to https://localhost . Whoops! That was not what I wanted in this case. To fix it, you need to go the network settings of your browser, there are available at: chrome://net-internals/#hsts edge://net-internals/#hsts brave://net-internals/#hsts Enter ‘localhost’ in the domain textbox under the Delete domain security policies section and hit Delete . That should do the trick…

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.