3 ms·

What kind, specifically? async/await in C# is a flaming tire fire of hot garbage, it's more a virus than a help. And why isn't an event driven API preferable?

kyberias 7y ago
Care to elaborate? I've been happily using async/await in C# without realizing how bad it is. It seems great, but maybe I don't just know enough. What should I know?
- lukevp 7y ago
  They’re probably referring to the warning in VS that async methods should be called from other async methods and aren’t a wait able otherwise, which causes async to propagate outward. This is imho not a big deal because you can decide at any point up the chain to make something synchronous by using .Result or .Wait() instead of awaiting it. It still makes everything downstream async. It’s a misunderstanding of the await keyword mostly. Await is essentially a yield you can place in a method that’s marked async but it’s not required for other called methods to have async/await patterns. Ultimately though the better way is to just make everything you can async.
  - onefuncman 7y ago
    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.

kyberias 7y ago

Care to elaborate? I've been happily using async/await in C# without realizing how bad it is. It seems great, but maybe I don't just know enough. What should I know?

lukevp 7y ago
They’re probably referring to the warning in VS that async methods should be called from other async methods and aren’t a wait able otherwise, which causes async to propagate outward. This is imho not a big deal because you can decide at any point up the chain to make something synchronous by using .Result or .Wait() instead of awaiting it. It still makes everything downstream async. It’s a misunderstanding of the await keyword mostly. Await is essentially a yield you can place in a method that’s marked async but it’s not required for other called methods to have async/await patterns. Ultimately though the better way is to just make everything you can async.
- onefuncman 7y ago
  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.