5 ms·
Agree with your complaint on async. And on asp.net, async doesn't disrupt that much the workflow (but creates the possibility for deadlocks). But if you are dea
by cm2187 6y ago
Agree with your complaint on async. And on asp.net, async doesn't disrupt that much the workflow (but creates the possibility for deadlocks). But if you are dealing with a UI and make a method async, then suddenly you have a ton more problems to deal with, like what happen if the user changes the state while you are waiting for an async call. That increases a lot the complexity of the code. Which is why I am lukewarm about their approach of mandating async for new features.
- spaetzleesser 6y agoAgreed. Async is nice on the server but on the desktop it’s a real problem. For a while they had both sync and async but now it’s often only async. I just finished an app that had to shutdown while some async operations were still not finished. Really hard to manage compared to using threads.
- lukevp 6y agoHow is Task.WaitAll different from Thread.Joining a bunch of threads? Or if you were cancelling tasks, using cancellation tokens?
- cm2187 6y agoIf you are running Task.WaitAll on a UI thread you are likely to create a deadlock.
- hansvm 6y agoThe other comment alluded to this, but the crux of the problem is that you can schedule a task to run and wait on the completion of that task, but the only available thread for it to run is the one currently waiting for it to complete. The writeup here isn't bad: https://devblogs.microsoft.com/pfxteam/await-and-ui-and-deadlocks-oh-my/ https://devblogs.microsoft.com/pfxteam/await-and-ui-and-dead...
- zmj 6y agoThe move to async trades one set of problems for another. Yes, implementing cooperative cancellation is tricky. On the other hand, recovering from corrupted state caused by Thread.Abort is also tricky.
- asyncawaaait 6y agoHow does async/await introduce complexity where threading wouldn’t? In my experience, the complexity is vastly reduced by not having to implement tricky asynchronous APIs (Task Paralell, thread pools, BackgroundWorker, etc).
- cm2187 6y agono, vs blocking the UI thread. Which is perfectly fine the vast majority of the cases, unless you are running something long running.
- huzaif 6y agoYou are trying to something slightly complex. I don't see how one could make it any easier from a language design perspective and staying idiomatic to the language. Go: Goroutines make you wire the "stop" scenario on your own (channel close). Rust: Hold on to your future and drop() it. C#: Pass a cancellation token and call Cancel() All seem reasonable and stay within what they think their developers will be able to pick up and run with.