Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asynchronous IO: the next billion-dollar mistake?

yorickpeterse.com

Post reply on HN
Print view View original

131–140 of 165 posts

Re: Asynchronous IO: the next billion-dollar mistake?

#131

Post by dist1ll »

Veserv wrote: post #105
ffsm8 wrote: post #82

Earlier quoted context omitted.

While that is technically true, it's also missing the point entirely. That's why I said you can have either blocking sync or non-blocking async. The article explicitly talks about the API provided by the OS. As a matter of fact, they're even more specific talking about spawning os threads vs async non-blocking file access. At this level, the async is an implementation detail. I guess your comment confirms that you di…

No, it shows you did not understand the context or the point of the comment you originally responded to. The author wants both synchronous and asynchronous modes, but they complain it is painful to provide asynchronous modes using synchronous primitives due to limitations of OS handling for such cases. dist1ll was pointing out how the lower abstraction level, the hardware, actually presents a asynchronous interface.…

Thank you, this was exactly my point. If efficiency is important, you want a very thin abstraction over hardware (in other words: library over frameworks).

This lack of hardware sympathy is actually something operating systems have been addressing in recent times. E.g. another top-level comment mentioned things like AF_XDP from the Linux kernel. I'm guessing similar ideas exist for modern, high-speed non-volatile storage (thinking of SPDK).

Also, your description of two wrongs is spot-on.

Re: Asynchronous IO: the next billion-dollar mistake?

#132

Post by josefrichter »

BenoitP wrote: post #74
josefrichter wrote: post #28

Isn’t that parallel universe actually the Erlang BEAM?

Or Go. Or Java' virtual threads. It must happen at the language level; When it comes to execution context knowledge: what context to compile out (stackless), or what context to serialize to the heap (stackful). Programming language will always know much more about the program than the OS. If I'm not mistaken in Erlang the programmer will provide the exact context to serialize : the actor.

I mentioned the BEAM as “universe” especially because it provides so much more than Go or Java in this respect.

Re: Asynchronous IO: the next billion-dollar mistake?

#133

Post by Paradigma11 »

sph wrote: post #63

Async 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.

I think CSP and Actors are overkill for nearly all programs. A simpler async system can do the job and introduce much less cognitive overhead. If really necessary there are still special libraries in most ecosystems like RX, Akka, Zio, Hopac, lwt......

Re: Asynchronous IO: the next billion-dollar mistake?

#134

Post by lossolo »

winternewt wrote: post #27

> Now imagine a parallel universe where instead of focusing on making asynchronous IO work, we focused on improving the performance of OS threads such that one can easily use hundreds of thousands of OS threads without negatively impacting performance I actually can't imagine how that would ever be accomplished at the OS level. The fact that each thread needs its own stack is an inherent limiter for efficiency, as sw…

Not to mention the security/mitigation overhead of context switches.

Re: Asynchronous IO: the next billion-dollar mistake?

#135

Post by nurettin »

In several projects I switched from async code to threads and mpsc queues. Timers, data streams, external communications all run in their threads. They pass their messages to the main thread's queue. The entire thing suddenly became much easier to reason about and read.

Re: Asynchronous IO: the next billion-dollar mistake?

#136

Post by tankenmate »

YorickPeterse wrote: post #129
tankenmate wrote: post #80

Earlier quoted context omitted.

I would concur, the author also mentions that file IO isn't async; this makes me conclude that the author hasn't grasped how much the Linux kernel has moved on since in the mid 2000s. I suspect that the author has an incomplete view of the current kernel / userland interface as well as the inner workings of how a kernel actually "does what it does".

That particular paragraph can be phrased better so I'll adjust that. What I meant to say is that you can't handle it asynchronously like you can with sockets, i.e. polling it for readiness. This is because for file IO, reads and writes are always reported as being available, making epoll/kqueue/etc effectively useless.

io_uring can poll filesystem descriptors for readiness; epoll, select, etc come from the networking world, and aio, etc come from the disk world, and as a result both have their various blinkers / limitations.

And I guess I could have phrased it better when I mentioned newer Linux developments, as io_uring does a far more comprehensive job of handling not just filesystem descriptors and network descriptors, but also other types of character devices.

Re: Asynchronous IO: the next billion-dollar mistake?

#137

Post by yencabulator »

torginus wrote: post #38

Asynchronous IO is just simply how the world works. Instead, the idea that changes happen only during CPU computation is the mistake. Your disk drive/network card exists in parallel to your CPU and can process stuff concurrently. Your CPU very likely has a DMA engine that works in parallel without consuming a hardware thread.

The "world" these days works by ringbuffers and interrupts, neither of which looks like async/await. Async/await is a chosen abstraction over what hardware/kernel interfaces really look like.

Re: Asynchronous IO: the next billion-dollar mistake?

#138

Post by yencabulator »

YorickPeterse wrote: post #129
tankenmate wrote: post #80

Earlier quoted context omitted.

I would concur, the author also mentions that file IO isn't async; this makes me conclude that the author hasn't grasped how much the Linux kernel has moved on since in the mid 2000s. I suspect that the author has an incomplete view of the current kernel / userland interface as well as the inner workings of how a kernel actually "does what it does".

That particular paragraph can be phrased better so I'll adjust that. What I meant to say is that you can't handle it asynchronously like you can with sockets, i.e. polling it for readiness. This is because for file IO, reads and writes are always reported as being available, making epoll/kqueue/etc effectively useless.

With io_uring, you don't poll a file descriptor for readiness and then attempt a non-blocking operation and hope it works. You submit a request and later get a response.

Re: Asynchronous IO: the next billion-dollar mistake?

#139

Post by yencabulator »

orf wrote: post #126

Computers are inherently asynchronous, we just plaster over that with synchronous interfaces. We put a lot of effort into maintaining these synchronous facades - from superscalar CPUs translating assembly instructions into “actual” instructions and speculatively executing them in parallel to prevent stalls, to the kernel with preemptive scheduling, threads and their IO interfaces, right up to user-space and the APIs…

https://en.wikipedia.org/wiki/Dataflow_architecture

https://stackoverflow.com/questions/530180/what-happened-to-...

Re: Asynchronous IO: the next billion-dollar mistake?

#140

Post by tankenmate »

baq wrote: post #92
tankenmate wrote: post #80

Earlier quoted context omitted.

I would concur, the author also mentions that file IO isn't async; this makes me conclude that the author hasn't grasped how much the Linux kernel has moved on since in the mid 2000s. I suspect that the author has an incomplete view of the current kernel / userland interface as well as the inner workings of how a kernel actually "does what it does".

> the author also mentions that file IO isn't async And the best part is that NT kernel was always async… Linux is actually kind of special in that it was primarily sync.

The Linux kernel isn't "primarily" sync, the kernel itself has been almost entirely async except for some small parts, like the bottom half of interrupt handlers which can't be pre-empted. Even in the early days of Linux the scheduler was pre-emptive and used "wait channels" create a synchronous interface for the asynchronous kernel. In the early days of Linux, if a process was in kernel mode then it couldn't be pre-empted until it returned to user mode, but this is no longer the case, and with PREEMPT_RT this is even the case for RT processes /kernel tasks.

Now, the POSIX API is largely synchronous, but this is mainly because of the history of UNIX (and Multics before it).

Post reply on HN