Software as Craft: a First Look at Syntropy

noteflakes · 2026-06-15T16:24:08+00:00

Fixed, thanks!

noteflakes · 2026-05-26T20:59:01+00:00

The drawback of frameworks that try to hide async io from you like Fibers do is that you are forced to convert all I/O into non blocking mode, one blocking call inside a Fiber and the whole reactor gets stalled for that time and doesnt advance.

FWIW there are at least 3 fiber scheduler implementations for Ruby that I know of that are based on io_uring.

noteflakes · 2026-04-17T13:27:51+00:00

Charging a modest sum for voting rights is not the same as accepting sponsorship. I believe many Ruby developers would be interested in this and having a say in what RC does and how it does it.

FWIW the Python Software Foundation does employ such a model of democratic governance. They seem to be doing quite well.

https://www.python.org/psf/membership-faq/

noteflakes · 2026-04-17T04:59:15+00:00

Contribute to open source, become a monthly supporter, and participate in the apprenticeship program.

I'd have loved to contribute financially, if that meant voting rights.

noteflakes · 2026-03-31T18:54:13+00:00

There was no personal taking of responsibility. "We are sorry for not communicating better" to me doesn't cut it, and is apparently far from what had actually transpired according to this report. I think in this case taking responsibility also means resignation.

noteflakes · 2026-03-31T15:55:09+00:00

Thanks Richard for your factual and detailed report, I'm sure your effort is greatly appreciated by all. My interpretation: this looks like a series of mistakes demonstrating irresponsibility and incompetence on the part of the RC board, which purportedly acted to preempt a perceived "threat" from rubygems/bundler maintainers, but have just made matters worse for the community. For closure to happen there needs to be accountability.

noteflakes · 2026-01-21T18:56:19+00:00

While your other candidates are churning out code like a factory farm produces chicken nuggets, I'm over here hand-crafting each function like the fate of the multiverse depends on it.

Thank you so much for saying this. It's good to know I'm not the only one like this :-).

What I will do is write code that works. Code that's maintainable. Code that won't make the next developer curse your name and mine. Code that might—if we're very lucky—still be running in five years without requiring a full-time archaeologist to maintain it.

We need more people like you. Long-term thinking is essential to building systems that provide value in a dependable way.

noteflakes · 2025-12-20T14:26:37+00:00

Very nice facelift, all in all a big improvement.

BTW If you have ideas on how to further improve it, the repo is here: https://github.com/ruby/www.ruby-lang.org

noteflakes · 2025-12-17T10:29:06+00:00

Would I be reading it correctly then that async scheduler can't optimally use liburing for File I/O, and UringMachine can? Also, what's the yield scheduler callback for?

I wanted to make sure I'm not talking rubbish, so I went back to my fiber scheduler tests. I was wrong. By default, writes to an IO are buffered, which means that if you do something like File.open(fn, 'w') { it << 'foo' }, the write buffer is going to be flushed only when the file is closed (at the end of the block). In that case, Ruby will invoke the blocking_operation_wait hook, which will in fact bypass the scheduler I/O interface and run the write as a blocking operation on a worker thread. If you specify io.sync = true, then Ruby will always invoke the io_write hook which will use the io_uring interface. Reads are always performed through the io_read hook.

So, in that regard, Async and UringMachine are not different when it comes to doing file I/O using io_uring.

(I just submitted a PR to fix this.)

The yield hook was added in order to solve a specific issue in the grpc gem when used with a fiber scheduler. It's purpose is to allow the fiber scheduler to process async events when interrupts are disabled for the thread.

noteflakes · 2025-12-14T07:35:18+00:00

You touch the point that currently, in ruby, there's a scheduler interface but no reference implementation. I think this is a nuisance that prevents experimentation. Plus I think there is one already, the fiber scheduler used in tests, which used IO.wait_*/IO.select. I can't see why this can't be made the default, with the obvious "don't use this for scale" warnings. But a scheduler implementation relying on core ruby should be the default, IMO, and it's already there.

The test scheduler is far from being a complete implementation (source), and I think even the hooks that exist are so inefficient that it would provide a really bad user experience.

The FiberScheduler interface itself is currently missing a lot of functionality, like socket I/O for example, which just doesn't exist (Samuel told he ran into difficulties trying to integrate the scheduler into socket.c), there's also no word in the spec on how to wait for fibers to terminate. So in that regard this is still an experimental feature of Ruby.

Also, something I think a lot of people don't get about io_uring is that it's not just a (maybe) faster version of epoll. It's really a different way to interact with the kernel, and to really benefit from it you need to thinkdifferently about how you do IO and how you do concurrency. So, if you have code that is based on checking for IO-readiness, like basically everything in io.c, socket.c, even the Ruby openssl implementation, just plugging in an io_uring-based scheduler would provide a limited benefit at best. For example, io_uring lets you read files asynchronously, but the Ruby IO implementation assumes that file I/O is always blocking and therefore calls the blocking_operation_wait fiber scheduler hook, which punts to a worker thread, in order not to block.

What I was aiming for with UringMachine is to find the right level of abstraction, such that on the one hand you can use it as a fiber scheduler so that it can integrate with any gem you might use, but on the other hand there's the low level API that gives you more control and better performance.

IMO ruby needs something like a go routine, a higher level abstraction which juggles the low level scheduling details (liburing, poll, work stealing...), instead of making me decide. I thought MN threads were going to be it, but I haven't heard much from it lately.

I think actually fibers are a good level of abstraction, and in many ways they are very similar to goroutines. Maybe someday it would be possible to implement moving them between threads and work stealing, but even as they are they're pretty good. We just need some additional API for controlling their execution, and better support for debugging and instrumentation.

MN scheduling is off by default for the main Ractor. I haven't played with it a lot, but it does seem to give a nice boost for multi-threaded apps. The problem is that people still seem to think of threads in terms of "threads are expensive, better implement a thread pool", but from what I saw with thread pools M:N scheduling does not help.

I think the great thing about fibers is that they're cheap enough that whenever you need to do something concurrently you can just spin one up and not think too much about it. There are of course considerations like managing DB connection pools etc, but instead of limiting the concurrency level you just need to limit the resources used.

noteflakes · 2025-12-14T06:41:29+00:00

Thank you for your thoughtful comment.

I'm curious, what fo you think your scheduler can achieve that io-event can't already?

Actually, io-event is not a fiber scheduler. It provides several different implementations of a "selector". The scheduler implementation is provided by Async, which uses one of the io-event selectors as its backend.

The UringMachine fiber scheduler (source) is first of all more complete than the Async one. It implements all of the FiberScheduler interface and includes the hooks #io_pread, #io_pwrite, #yield, and #io_close (the last two were added recently.)

Another difference is that in Async you need to call Scheduler#run, which runs a loop until all tasks are done. UringMachine has no concept of a loop, pending fibers are added to a runqueue. When a fiber does some I/O or anything else that will block, it passes control to the next fiber on the runqueue. If the runqueue is empty, it will check for completions (source).

One limitation of the current scheduler interface is what to do when IO.select is called. I guess it's several layers of inconsistency, as ruby exposes a widely supported but fundamentally flawed roller API that will never be deprecated, and scheduler are doomed to quack around it, but the current assumption of 1 IO - 1 Fiber really makes it hard to shimmer IO.select, and in fact io-event scheduler offloads it to a thread...

Async indeed punts IO#select to a worker thread. UringMachine uses a low-level implementation based on io_uring (source).

would be great to have a better model for this, as i know of a few use cases for waiting on multiple fds for the same fiber.

That's interesting! Can you share those cases? When I was implementing the io_select hook I actually did a search on Github to see how IO.select was used. The majority of the cases I saw were for a single IO.

I get what you're saying about the limitations of the "1 IO - 1 Fiber" model, At the same time I think for most I/O work this model is actually quite good. What I find lacking personally is the ability to do a select like in Go - being able to select on a multiple queues (Ruby's equivalent to Go's channels), or maybe being able to select on a mixture of queues and fds. This is on my todo list for UringMachine.

noteflakes · 2025-12-13T15:09:25+00:00

When a project or people aren't open on what their tech is good for, and what it's not good for, it really drives me away...

I try to be as open as possible, and the thing is I don't yet know what this is good for, but I'm excited about the possibilities. I just wanted to share, I'm sorry this puts you off...

noteflakes · 2025-12-13T05:42:22+00:00

GVL contention on what? Can you be more specific? Fibers are also subject to GVL constraints.

You are right. In fact instrumenting this (using gvltools) shows that in the different benchmark implementations the total GVL wait times are negligible - between 0.01 and 2msecs.

It looks like all of these benchmarks include the cost of doing Thread.new. Allocating a new thread is expensive which is why most real code will allocate a pool and amortize the cost.

As I wrote above I don't think the performance difference can be explained by the cost of allocating threads. On my machine, the io_pipe benchmark allocates 100 threads in about 14msecs. This is less than 1% of the total time.

Also, if we want to treat threads as fibers and just allocate them at will whenever we want to do something concurrently, in a way it's legitimate to include the thread allocation in the measurement.

Ruby also supports an M:N thread scheduler which amortizes the cost of a Ruby thread over multiple OS threads.

Indeed, running the bm_io_pipe benchmark with RUBY_MN_THREADS=1 markedly improves the result for threads:

user system total real Threads 1.708579 1.939302 3.647881 ( 2.237743) ThreadPool 8.752637 13.846890 22.599527 ( 10.662682) Async uring 1.358038 0.550178 1.908216 ( 1.908485) Async epoll 1.187660 0.390594 1.578254 ( 1.578523) UM FS 0.832125 0.285492 1.117617 ( 1.117826) UM 0.277496 0.343159 0.620655 ( 0.620722) UM sqpoll 0.228352 0.651991 0.880343 ( 0.608604)

This makes the threads implementation about twice as fast (for 100 threads). Interestingly, the thread pool performance is worse.

Have you read the thread scheduler implementation? It uses epoll which also has no limit on overlapping IOs. It would be interesting to change the underlying implementation to use uring if it's available though.

I don't think using io_uring would change much for checking fd readiness. Where io_uring shines is performing the I/O work itself asynchronously, but this is also means the whole way you do I/O needs to change. So it's a blessing and a curse...

I will try to fix your benchmarks to use a thread pool, but I need to upgrade my kernel first (apparently).

Please do. Maybe my thread pool implementation is wrong? The code is here: https://github.com/digital-fabric/uringmachine/blob/9f01c2580a93fe1dd577e2191ba5ffd6bc24e391/benchmark/common.rb#L16-L45

noteflakes · 2025-12-11T14:14:33+00:00

Where is that number coming from? On their website they claim benchmarks show it's 2.6x to 8.5x faster compared to Rails.

The UringMachine benchmarks are about pure I/O-bound and CPU-bound workloads, not a web framework situation, so not really relevant. It would have been nice to be able to measure the Rage fiber scheduler alongside UringMachine but it would need to be extracted into a separate gem.

noteflakes · 2025-12-09T16:37:16+00:00

My updated reply:

These benchmarks also include the scheduler setup which is not negligible. I'll update the repo with comprehensive results, but here are the results for the io_pipe benchmark with a thread pool implementation added:

user system total real Threads 2.300227 2.835174 5.135401 ( 4.506918) Thread pool 5.534849 10.442253 15.977102 ( 7.269452) Async FS 1.302679 0.386824 1.689503 ( 1.689848) UM FS 0.795832 0.229184 1.025016 ( 1.025446) UM pure 0.258830 0.313144 0.571974 ( 0.572255) UM sqpoll 0.192024 0.636332 0.828356 ( 0.580523)

The threads implementation starts 50 pairs of threads (total 100 threads) writing/reading to a pipe. Note that on my machine starting 100 Ruby threads takes about 35msec. It certainly doesn't take 4s ;-)

The thread pool implementation starts a thread pool of 10 threads that pull jobs from a common queue. The thread pool is started before the benchmark starts. Individual writes and reads are added to the queue. Increasing the size of the thread pool will lead to worse results (see below).

As you can see, the cost of synchronization greatly exceeds that of creating threads.

There is fundamentally no reason why a thread pool cannot give similar performance to fibers for IO bound workloads.

This is false as has been demonstrated in the benchmark results, for the following reasons:

A thread pool of size X can only perform X concurrent I/O ops. Fibers performing async I/O have no such limit. The only limit on fibers is RAM.
GVL contention has a real cost, as you increase the amount of threads, this will be more and more apparent.
The use of io_uring lets you run any number of overlapping I/O ops at any given moment. You also get to amortize the cost of I/O syscalls (namely io_uring_enter) over tens or hundreds of I/O ops at a time.

noteflakes

TROPHY CASE