Take the title at face value. If it were a sincere question the sincere answer is simply no.
The world actually is concurrent and asynchronous regardless how inconvenient that is for a programmer.
Asynchronous IO: the next billion-dollar mistake?
121–130 of 165 posts
Re: Asynchronous IO: the next billion-dollar mistake?
#122Earlier quoted context omitted.
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.
But the same way the CPU works very hard to hide that away from you (reordering, caches, etc), green threads could do the same with barely any performance hit.
Re: Asynchronous IO: the next billion-dollar mistake?
#123Earlier 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?
Java threads were killable originally. Then it turned out to be impossible to use safely, so it got deprecated: https://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadP...
Re: Asynchronous IO: the next billion-dollar mistake?
#124Earlier quoted context omitted.
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.
Shared-nothing threads? So basically processes.
Re: Asynchronous IO: the next billion-dollar mistake?
#125On the contrary blocking IO (and POSIX) is the old billion dollar mistake.
It's inefficient and blocks concurrency safety.
Re: Asynchronous IO: the next billion-dollar mistake?
#126Computers 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 they provide on top of all this.
Surely there has to be a better way? It seems ridiculous.
Re: Asynchronous IO: the next billion-dollar mistake?
#127Synchronous IO has always been more efficient. Anyone that thought otherwise doesn't understand how complicated context switches are in CPUs. The benefit of async io has always been handling tons of idle connections.
Anyone that thought otherwise doesn't understand how complicated context switches are in CPUs That’s not true. I understand how context switches work down to tss records, but can’t immediately see why nonblock should be less efficient. Is it due to for-rw vs for-poll-rw? Doesn’t kqueue/iocp ought to solve that?
kqueue, like all non-io_uring implementations on Linux, are synchronous under the hood.
Re: Asynchronous IO: the next billion-dollar mistake?
#128> 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 fo…
Linux and Windows are limited by the commit limit when it comes to threads. Linux has a default thread stack size of 8Mb vs. NT of 1Mb, in theory meaning Linux will run out of allocation space much quicker.
But in the end, both are limited by available memory.
Re: Asynchronous IO: the next billion-dollar mistake?
#129> "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".
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.
Re: Asynchronous IO: the next billion-dollar mistake?
#130> 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 t…
Is this actually proven though? I've seen other people argue that threads are already as fast as they can be, yet nobody is able to actually substantiate that claim.