3 ms·

There's terrible dangers that await one who casually throws .Result or .Wait() into an existing ASP.NET application. The intersection between synchronous and a

There's terrible dangers that await one who casually throws .Result or .Wait() into an existing ASP.NET application. The intersection between synchronous and asynchronous code is the ugliest. The most dangerous is how deadlocks can arise because of the execution context of a running application vs the execution context of your unit tests. If you're already in .NET Core, you're probably fine. For more, try https://devblogs.microsoft.com/pfxteam/should-i-expose-synchronous-wrappers-for-asynchronous-methods/ https://devblogs.microsoft.com/pfxteam/should-i-expose-synch... or any of Stephen Cleary's blog posts https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html https://blog.stephencleary.com/2012/07/dont-block-on-async-c...

DSMan195276 7y ago
> If you're already in .NET Core, you're probably fine. Note it's not quite that simple. It's true that ASP.Net Core uses the default synchronization context, and thus will not generally deadlock if a thread `await`s a `Task` that was started on the same thread (Because it can get resumed on a different one), but that doesn't mean there are no problems with this approach. An ASP.Net Core app is not going to start up as many threads as a ASP.Net one by default, and will do so much slower (And I believe there is also a lower limit on the max number of threads, though I'm not 100% sure. The article you linked says it was 25 for 1.0, but I'm not sure about the limit for 2.X or 3.X versions). Point being, if you're blocking threads by waiting on other tasks, it is still possible you encounter deadlocks or big performance drops because there are no threads currently available to run the task (And none are getting spun up to handle it). ASP.Net Core is somewhat "worse" in this regard because of what I put above - Even if you're not hitting the deadlocks you would get in ASP.Net, if you have a lot of blocking actions that you haven't converted to be `async` then you're going to potentially hit bad performance issues due to the fact that the starting thread-pool is much smaller, resulting in a lot less requests getting processed (Because a completely `async` pipeline shouldn't require a large thread-pool to process). And, if for some reason the thread pool is exhausted and no new threads are getting created, you can still get deadlocked like before. If you're going to ASP.Net Core, you should really make your pipeline completely `async` to avoid running into issues.

DSMan195276 7y ago

> If you're already in .NET Core, you're probably fine. Note it's not quite that simple. It's true that ASP.Net Core uses the default synchronization context, and thus will not generally deadlock if a thread `await`s a `Task` that was started on the same thread (Because it can get resumed on a different one), but that doesn't mean there are no problems with this approach. An ASP.Net Core app is not going to start up as many threads as a ASP.Net one by default, and will do so much slower (And I believe there is also a lower limit on the max number of threads, though I'm not 100% sure. The article you linked says it was 25 for 1.0, but I'm not sure about the limit for 2.X or 3.X versions). Point being, if you're blocking threads by waiting on other tasks, it is still possible you encounter deadlocks or big performance drops because there are no threads currently available to run the task (And none are getting spun up to handle it). ASP.Net Core is somewhat "worse" in this regard because of what I put above - Even if you're not hitting the deadlocks you would get in ASP.Net, if you have a lot of blocking actions that you haven't converted to be `async` then you're going to potentially hit bad performance issues due to the fact that the starting thread-pool is much smaller, resulting in a lot less requests getting processed (Because a completely `async` pipeline shouldn't require a large thread-pool to process). And, if for some reason the thread pool is exhausted and no new threads are getting created, you can still get deadlocked like before. If you're going to ASP.Net Core, you should really make your pipeline completely `async` to avoid running into issues.