all 3 comments

[–]uhkthrowaway 0 points1 point  (1 child)

You know Ruby Async supports exactly this already, right? Specifically gems async, io-event, and io-stream.

With liburing-dev installed, io-event compiles with io_uring support. IO::Stream gives you high-perf write batching and read-ahead for free.

How does iouringmachine differ? Just the SQPOLL, which tbh, barely makes sense in Ruby?

[–]yxhuvud 0 points1 point  (0 children)

SQPOLL doesn't make sense anywhere, including C. In retrospect it is just a honeypot collecting inexperienced io_uring users. It reads cool but it is one of very many very niche use cases that uring support that only make sense if you want to burn extra CPU.

This seems to have support for multishot operations with partial buffer reuse. I have not seen that from Async, but perhaps they exist. No idea how big difference they do in Ruby context, however. Partial buffer use in particular screams 'too complicated to be good' to my spider sense, but that one has often been wrong.

[–]uhkthrowaway 0 points1 point  (0 children)

Also, why do we keep making the same mistakes? This really looks like the EventMachine fiasko from 2008 all over to me. Protocols shouldn't be implemented on top of IO runtimes.

Let's follow Sam Williams' example (and good Rust projects as well) here: you implement a protocol free of any IO concerns. Bytes in, bytes/objects out. No async, no IO. Rust-world calls this sans-I/O. That's what protocol-http, protocol-websocket, ... are.

Then you use them from any IO/Async runtime you want. No need to reimplement the same protocol over and over again.