You wanna know what else didn't ship with async? The thing all your bullshit async websocket servers run on: Linux. Last time I checked, Linux, and the POSIX world in whole, seems to be doing just fine running the entire internet without it. signal, timerfd, epoll, kqueue exist. Guess what? That's all tokio and these runtimes are doing. They can't magically put something to sleep. The kernel is the one who's not bringing your CPU to a halt when your read isn't doing anything, not tokio.
Linux since 5.11/5.15 timeframe has shipped with an growingly speedy & capable async, io-uring. There are still security issues, to the degree that Google has started simply disabling io-uring. But for many application-servers, it feels like the risk today is minimal and it feels probable the situation will improve over time; I for one would not bet against io-uring.
If anything I think there's a huge possibility to write really good languages or standard libraries that dive headfirst into this better new world. I view there as being a huge late mover advantage, ready for the taking, now that operating systems have finally gotten good, now that we can offload work so effectively to the kernel. There's works like https://github.com/tokio-rs/io-uring to make use of io-uring, but I worry that it only covers slices of what could be possible, that it's just cutting out a single path of use, and that path is deeply constrained by path dependence. It'd be interesting to see what a (not necessarily Rust) stdlib would look like that was io-uring first, that tries to enable a significantly wide breadth of async usage.
I'm also interested & excited to see if wasm (& wasi) can start to make good use of the new excellent async that has bloomed so recently. Wasm's component-model is in the midst of trying to de-colorize function calls, allow async/sync code to call each other, which is quite an endeavor and something that - if it works - could provide great relief to this time of strife.
Briefly scanning the sample code here, evidence is that this person is also quite bad at async themselves. I don't see evidence that they've absorbed any of the lessons on the many many pitfalls of epoll. Or go read the systemd author's write-up on why epoll was hard for them. There's a reason that there are dozens of event-loop libraries out there; conceptually it seems simple but this stuff is incredibly difficult to get right! Also, a quick scan hasn't shown any notable epoll improvements in the past ~8 years; would love to be found wrong on that. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-...https://news.ycombinator.com/item?id=13736674http://0pointer.net/blog/introducing-sd-event.html . To the counter, there is also a epoll defense using EPOLLET (edge triggered): https://gottliebtfreitag.de/blog/2019/09/14/Epoll.html .
Comments
Linux since 5.11/5.15 timeframe has shipped with an growingly speedy & capable async, io-uring. There are still security issues, to the degree that Google has started simply disabling io-uring. But for many application-servers, it feels like the risk today is minimal and it feels probable the situation will improve over time; I for one would not bet against io-uring.
If anything I think there's a huge possibility to write really good languages or standard libraries that dive headfirst into this better new world. I view there as being a huge late mover advantage, ready for the taking, now that operating systems have finally gotten good, now that we can offload work so effectively to the kernel. There's works like https://github.com/tokio-rs/io-uring to make use of io-uring, but I worry that it only covers slices of what could be possible, that it's just cutting out a single path of use, and that path is deeply constrained by path dependence. It'd be interesting to see what a (not necessarily Rust) stdlib would look like that was io-uring first, that tries to enable a significantly wide breadth of async usage.
I'm also interested & excited to see if wasm (& wasi) can start to make good use of the new excellent async that has bloomed so recently. Wasm's component-model is in the midst of trying to de-colorize function calls, allow async/sync code to call each other, which is quite an endeavor and something that - if it works - could provide great relief to this time of strife.
Briefly scanning the sample code here, evidence is that this person is also quite bad at async themselves. I don't see evidence that they've absorbed any of the lessons on the many many pitfalls of epoll. Or go read the systemd author's write-up on why epoll was hard for them. There's a reason that there are dozens of event-loop libraries out there; conceptually it seems simple but this stuff is incredibly difficult to get right! Also, a quick scan hasn't shown any notable epoll improvements in the past ~8 years; would love to be found wrong on that. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-... https://news.ycombinator.com/item?id=13736674 http://0pointer.net/blog/introducing-sd-event.html . To the counter, there is also a epoll defense using EPOLLET (edge triggered): https://gottliebtfreitag.de/blog/2019/09/14/Epoll.html .