Our great sponsors
-
Concurrent Ruby
Modern concurrency tools including agents, futures, promises, thread pools, supervisors, and more. Inspired by Erlang, Clojure, Scala, Go, Java, JavaScript, and classic concurrency patterns.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
https://github.com/ruby-concurrency/concurrent-ruby seems to be the current king of concurrency in Ruby. A lot of different concurrency models are implemented so you can pick whichever makes the most sense for you. The downside is that since the library doesn't focus on one model over another, it's probably difficult to learn for beginners.
Lastly, if anything that I wrote here is wrong or inaccurate please correct me, but please don't take it personally! As I wrote in the libev_scheduler README, at worst I'm just some random guy being wrong on the internet. :-)
I added some more information about the Polyphony-based script here: https://github.com/jsaak/ruby3-tcp-server-mini-benchmark/issues/1
There's the Polyphony project, which implements seamless concurrency on top of Ruby fibers. It's still not production-grade, but is used in production. Polyphony follows a different path in that it allows developers to continue using the Ruby core and stdlib APIs, and consequentially large parts of the Ruby ecosystem, in a multi-fiber environment. It puts a strong emphasis on structured concurrency, robust error handling and providing concurrency primitives that can be used to implement all kinds of concurrency patterns, such as actors (message passing between different fibers) and supervision trees.
As far as tools based on Polyphony, currently there's Tipi, a web server based on Polyphony that is still in early stages of development, but already supports HTTP/1, HTTP/2, SSL termination and WebSockets, among other things.
Samuel, I've just taken a look at the io.c code, which interacts with the scheduler interface, to verify whether I'm wrong or not. And now I see that in fact you have added read and write hooks that were merged into Ruby master about two weeks ago, so I stand corrected.
As for your other comment on this thread, I think you'll agree that it's important to make a distinction between using io_uring for I/O readiness and using io_uring for performing actual I/O. The nio4r gem is based on libev, and libev now has an (experimental) io_uring backend, but its only use is for checking I/O readiness. The evt gem includes code for performing reads and writes using io_uring, but at the present moment it's currently disabled.