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

91–100 of 165 posts

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

#91

Post by yas_hmaheshwari »

BenoitP wrote: post #11

> Now imagine a parallel universe where instead of focusing on making asynchronous IO work Funny choice of words. In the JVM world, Ron Pressler's first foray into fibers -quasar- was named "parallel universe". It worked with a java agent manipulating bytecode. Then Ron went to Oracle and now we have Loom, aka a virtual thread unmounted at each async IO request. Java's Loom is not even mentioned in the article. I won…

1. I liked the way Java did not implement the async await style, and waited for the right abstraction with Project loom.

2. Though for a single threaded language like Javascript, I like the whole async await style because the alternative was worse (promises, callbacks )

Did not knew this history of how Project Loom came to be (though Quasar)

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

#92

Post by baq »

tankenmate wrote: post #80
seanhunter wrote: post #73

> "Not only would this offer an easier mental model for developers..." Translation: "I find async i/o confusing and all developers are like me". This argument has been going on for over 20 years at this point. There are some people who think having pools of threads polling is a natural way of thinking about IO. They keep waiting for the day this becomes an efficient way to do IO.

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.

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

#93

Post by scotty79 »

meindnoch wrote: post #65
bjornsing wrote: post #49

Earlier quoted context omitted.

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

Can you have leaks when everything is garbage collected?

Do deadlocks occur if killable threads aren't allowed to wait for other threads?

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

#95

Post by bob1029 »

> the cost to start threads is lower, context switches are cheaper, etc.

Physics would have a word with this one. We are already pushing limits of what is possible with latency between cores vs overall system performance. There isn't an order of magnitude improvement hiding in there anywhere without some FTL communication breakthrough. In theory, yes we could sweep this problem under the rug of magical, almost-free threads. But these don't really exist.

I think the best case for performance is to accumulate mini batches of pending IO somewhere and then handle them all at once. IO models based upon ring buffers are probably getting close to the theoretical ideal when considering how our CPUs work internally (cache coherency, pipelining, etc).

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

#96

Post by neonsunset »

No, it isn’t, the author is just confused, as it usually is.

Worked great in C# since its introduction for task interleaving, composition, cancellation (worse languages call it structured concurrency) and switching to privileged context (UI thread), and will work even better in .NET 10.

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

#97

Post by zarzavat »

vbezhenar wrote: post #48
dist1ll wrote: post #36

Earlier 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…

> So really, async I/O is the natural abstraction for networking. Special pointer values are also natural abstraction.

They’re a natural implementation detail. They could be exposed by the programming language as some other type than SomeObject* or SomeReference.

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

#98

Post by pjc50 »

bjornsing wrote: post #49
haileys wrote: post #10

Asynchronous 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?

Killing threads uncooperatively wrecks all your other concurrency primitives.

Not a theoretical consideration, for example we recently discovered that with GRPC Java if you kill a thread while it is making a request, it will leave the channel object in an unusable state for all other threads.

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

#99

Post by harry8 »

Animats wrote: post #37
jiggawatts wrote: post #4

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

There is a history of trying to support context switching in CPU hardware. That was a hot idea decades ago. Intel had call gates and some other stuff. Some of the RISC machines had hardware to spill all the registers to memory in background. Some early machines, from the days where CPUs were slower than memory, just had a context pointer in hardware. Change that and you're running a different thread. None of this hel…

> a consequence of C winning. C likes a single flat address space.

Interesting.

What other language did C beat? How was their address space handling different?

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

#100

Post by pjc50 »

scotty79 wrote: post #93
meindnoch wrote: post #65

Earlier quoted context omitted.

That's a sure way to get leaks and deadlocks.

Can you have leaks when everything is garbage collected? Do deadlocks occur if killable threads aren't allowed to wait for other threads?

You can probably make this work if and only if the thread is shared-nothing. If you share any data structure with another thread then you have the possibility of leaving it in an invalid state when killed.

This also requires any "channel" primitives you use for inter-thread communication to be tolerant of either thread being killed at any instruction boundary, which is hard to design.

Post reply on HN