4 ms·

I would argue that async/await is far more important for native applications. I've seen plenty of apps doing significant work on the UI thread and hanging. Maki

I would argue that async/await is far more important for native applications. I've seen plenty of apps doing significant work on the UI thread and hanging. Making it easy for developers to run things in the background is great for performance. Web browsers automatically add a level of asynchronous interaction. It's also important on a web server but it won't improve performance for a single user in isolation. As you say, it allows more requests to be serviced concurrently. This won't speed up an individual request unless the server is already heavily loaded. Edit: You don't need to build two library APIs. You can just build an Async method as the default implementation then have a blocking call to that as the synchronous method. I believe that all new MS APIs are now Async by default.

recursive 10y ago
Async/Await does not imply multiple threads. Often, the async version will use fewer threads than the equivalent synchronous code. http://blog.stephencleary.com/2013/11/there-is-no-thread.html http://blog.stephencleary.com/2013/11/there-is-no-thread.htm...
dhd415 10y ago
>>I would argue that async/await is far more important for native applications. I've seen plenty of apps doing significant work on the UI thread and hanging. Making it easy for developers to run things in the background is great for performance. Web browsers automatically add a level of asynchronous interaction.<< You can achieve the same thing in a GUI app by simply off-loading the long-running operation to a separate thread. The same is _not_ true for a highly concurrent, I/O-heavy server workload. That's where async/await is necessary and not just a syntactic convenience.
caleblloyd 10y ago
> You don't need to build two library APIs. You can just build an Async method as the default implementation then have a blocking call to that as the synchronous method This can lead to a nasty problem: Thread Pool Starvation. I contribute to MySqlConnector, an MIT Licensed MySql driver for .NET that implements truly Asynchronous I/O. We did this at first, but had to do a large refactor because we hit Thread Pool Starvation in our high concurrency performance tests. Here's the original issue: https://github.com/mysql-net/MySqlConnector/issues/62 https://github.com/mysql-net/MySqlConnector/issues/62 Stephen Toub has a pretty good article explaining why you shouldn't do "Sync over Async": https://blogs.msdn.microsoft.com/pfxteam/2012/04/13/should-i-expose-synchronous-wrappers-for-asynchronous-methods/ https://blogs.msdn.microsoft.com/pfxteam/2012/04/13/should-i...

recursive 10y ago

Async/Await does not imply multiple threads. Often, the async version will use fewer threads than the equivalent synchronous code. http://blog.stephencleary.com/2013/11/there-is-no-thread.html http://blog.stephencleary.com/2013/11/there-is-no-thread.htm...

dhd415 10y ago

>>I would argue that async/await is far more important for native applications. I've seen plenty of apps doing significant work on the UI thread and hanging. Making it easy for developers to run things in the background is great for performance. Web browsers automatically add a level of asynchronous interaction.<< You can achieve the same thing in a GUI app by simply off-loading the long-running operation to a separate thread. The same is _not_ true for a highly concurrent, I/O-heavy server workload. That's where async/await is necessary and not just a syntactic convenience.

caleblloyd 10y ago

> You don't need to build two library APIs. You can just build an Async method as the default implementation then have a blocking call to that as the synchronous method This can lead to a nasty problem: Thread Pool Starvation. I contribute to MySqlConnector, an MIT Licensed MySql driver for .NET that implements truly Asynchronous I/O. We did this at first, but had to do a large refactor because we hit Thread Pool Starvation in our high concurrency performance tests. Here's the original issue: https://github.com/mysql-net/MySqlConnector/issues/62 https://github.com/mysql-net/MySqlConnector/issues/62 Stephen Toub has a pretty good article explaining why you shouldn't do "Sync over Async": https://blogs.msdn.microsoft.com/pfxteam/2012/04/13/should-i-expose-synchronous-wrappers-for-asynchronous-methods/ https://blogs.msdn.microsoft.com/pfxteam/2012/04/13/should-i...