Asynchronous IO: the next billion-dollar mistake?
yorickpeterse.com
Asynchronous IO: the next billion-dollar mistake?
1–10 of 165 posts
Re: Asynchronous IO: the next billion-dollar mistake?
#2[deleted]
Re: Asynchronous IO: the next billion-dollar mistake?
#3I generally agree with this article.
There are programs where async IO is great, but in my experience it stops being useful as your code “does more stuff”.
The few large scale async systems I’ve worked with end up with functions taking too long, so you use ability to spin off functions into threadpools, then async wait for their return, at which point you often end up with the worst of both threads and async.
Re: Asynchronous IO: the next billion-dollar mistake?
#4There are fundamental reasons for OS threads being slow, mostly to do with processor design. Changing the silicon would be hundreds of times more expensive than solving the problem in software in user mode.
This is a billion-dollar solution to a hundred-billion dollar problem.
Re: Asynchronous IO: the next billion-dollar mistake?
#5Interesting take. I’d like to see such an OS, I wonder what requirements/limitations it would have.
Re: Asynchronous IO: the next billion-dollar mistake?
#6We do live in the universe of high performance threads with asynchronous I/O.
The author is looking for Windows NT.
Re: Asynchronous IO: the next billion-dollar mistake?
#7> More specifically, what if instead of spending 20 years developing various approaches to dealing with asynchronous IO (e.g. async/await), we had instead spent that time making OS threads more efficient, such that one wouldn't need asynchronous IO in the first place?
This is still living in an antiquated world where IO was infrequent and contained enough that one blocking call per thread still made you reasonable forward progress. When you’re making three separate calls and correlating the data between them having the entire thread blocked for each call is still problematic.
Linux can handle far more threads than Windows and it still employs io_uring. Why do you suppose that is?
One little yellow box about it is not enough to defend the thesis of this article.
Re: Asynchronous IO: the next billion-dollar mistake?
#8What about memory? the real price of threads is the stack.
Even when perfectly optimized, it wouldn't be enough to handle serious workloads.
Re: Asynchronous IO: the next billion-dollar mistake?
#9you should be able to reason synchronously and a good computer system would handle the rest.
Re: Asynchronous IO: the next billion-dollar mistake?
#10Asynchronous IO isn't about efficiency.
The approach the author takes with their language is just threads, but scheduled in userland. This model allows a decoupling of the performance characteristics of runtime threads from OS threads - which can sometimes be beneficial - but essentially, the programming model is fundamentally still synchronous.
Asynchronous programming with async/await is about revealing the time dimension of execution as a first class concept. This allows more opportunities for composition.
Take cancellation for example: cancelling tasks under the synchronous programming model requires passing a context object through every part of your code that might call down into an IO operation. This context object is checked for cancellation at each point a task might block, and checked when a blocking operation is interrupted.
Timeouts are even trickier to do in this model, especially if your underlying IO only allows you to set per-operation timeouts and you're trying to expose a deadline-style interface instead.
Under the asynchronous model, both timeouts and cancellation simply compose. You take a future representing the work you're doing, and spawn a new future that completes after sleeping for some duration, or spawn a new future that waits on a cancel channel. Then you just race these futures. Take whichever completes first and cancel the other.
Having done a lot of programming under both paradigms, the synchronous model is so much more clunky and error-prone to work with and involves a lot of tedious manual work, like passing context objects around, that simply disappears under the asynchronous model.