Google's SwitchTo kernel patches are similar to what you describe: https://lore.kernel.org/lkml/20200722234538.166697-1-posk@po...
Slides: https://web.archive.org/web/20200802205544/https://pdxplumbe...
Asynchronous IO: the next billion-dollar mistake?
61–70 of 165 posts
Re: Asynchronous IO: the next billion-dollar mistake?
#62"Not every IO operation can be performed asynchronously though. File IO is perhaps the best example of this (at least on Linux). To handle such cases, languages must provide some sort of alternative strategy such as performing the work in a dedicated pool of OS threads."
Can someone explain, why this would be the case?
- Why can't every IO op be async?
- Why is file IO on Linux not async?
- What does iouring have to do with it?
Re: Asynchronous IO: the next billion-dollar mistake?
#63Async IO is hilarious in a universe where Hewitt's actors or even Hoare's CSP exist.
They are a subpar technique that works well with languages with semantics from the 1970s that do not have communication primitives, in the age of multicore and the Internet.
The saddest thing is the most hyped language of the decade went all in with this miserable idea, and turned me completely off the ecosystem.
Re: Asynchronous IO: the next billion-dollar mistake?
#64There's an effort by Google to address this with userspace threads. I think it has stalled though.
HN discussion thereof: https://news.ycombinator.com/item?id=23964633
Re: Asynchronous IO: the next billion-dollar mistake?
#65Asynchronous 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 di…
> 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. Does it? Wouldn’t you just kill the thread in the synchronous model?
That's a sure way to get leaks and deadlocks.
Re: Asynchronous IO: the next billion-dollar mistake?
#66Async IO is hilarious in a universe where Hewitt's actors or even Hoare's CSP exist. They are a subpar technique that works well with languages with semantics from the 1970s that do not have communication primitives, in the age of multicore and the Internet. The saddest thing is the most hyped language of the decade went all in with this miserable idea, and turned me completely off the ecosystem.
How is CSP different from async/await?
One is a semantics and the other is a syntax, no?
Re: Asynchronous IO: the next billion-dollar mistake?
#67Somewhat controversial take: the current threads implementation is usually already performant enough for most use cases. The actual reason why we don't use them to handle more than a few thousand concurrent operations is that, at least in Linux, threads are scheduled and treated very similarly to processes. E.g. if a single process with 3000 threads gets bottlenecked on some syscall, etc, your system load average will become 3000, and it will essentially lead to no other processes being able to run well on the same machine.
Another issue with threads performance is that they are visible to most system tools like `ps`, and thus having too mamy threads starts to affect operations _outside_ the kernel, e.g. many monitoring tools, etc.
So that's the main reason why user-space scheduling became so popular: it hides the "threads" from the system, allowing for processes to be scheduled more fairly (preventing stuff like reaching LA 3000 when writing to 3000 parallel connections), and not affecting performance of the system infrastructure around the kernel.
BTW the threads stacks, as well as everything else in Linux are allocated lazily, so if you only use like 4Kb of stack in the thread it wouldn't lead to RSS of full 8M. It will contribute to VMEM, but not RSS
Re: Asynchronous IO: the next billion-dollar mistake?
#68Earlier quoted context omitted.
> But at the programming language level the compiler does have insight into the dependencies of your continuation This is really the key point - coupled with the fact that certain I/O operations are just inherently asynchronous. The TX/RX queues in NICs are an async, message passing interface - regardless of whether you're polling descriptors or receiving completion interrupts. So really, async I/O is the natural abs…
Anything that happens far enough from the CPU is async, and here far probably means 10cm thanks to the speed of light not being fast enough, even in vacuum. So, any computation that spans a machine the size of our hands needs async unless you are willing to drop the clocks to push "far" a bit further away (and bring in power, heat and noise with it).
Thanks for putting words into this.
Another cut off could be 3 cm away: the RAM. If data needs to go on the heap, be shared, one can consider the truth lives farther away than 3cm and thus has async/impure effects.
Re: Asynchronous IO: the next billion-dollar mistake?
#69Async/await is a language semantics thing. It's not really relevant whether there's a "real" OS thread under the hood, some language level green thread system, or just the current process blocking on something - the syntax exists because sometimes you don't want to block on things that take a long time semantically - I.e. you want the next line of code to run immediately. You could absolutely write a language where t…
Async/await and threading+blocking are ultimately duals of each other. You can express the same semantics with one model or the other, regardless of the underlying implementation of either. You could in fact implement multi-threading and blocking on top a task-based API if you wanted to - e.g. you could implement a Java style Threads API in JS if you really wanted to (of course, code would still run single threaded, like in old times with single-CPU systems).
Re: Asynchronous IO: the next billion-dollar mistake?
#70you should be able to reason synchronously and a good computer system would handle the rest.
You cannot reason synchronously about things that are asynchronous. Unless you want to just block on IO. Which is clearly not great as a user experience or very efficient.