To close the loop here, yes, I was wrong: 1sec should be expected, not 10. Without MN_THREADS, the 0.1msec sleep becomes a 1msec sleep. With MN_THREADS, the 0.1msec sleep is skipped completely. I see the second of theses issues is now...jpl-coconut (Jacob Lacouture)
I created a benchmark for the purpose of testing [a fix](https://github.com/ruby/ruby/pull/15840) for [Issue 21685](https://bugs.ruby-lang.org/issues/21685) The benchmark is inline below and saved as 100usec.rb. It should always take ...jpl-coconut (Jacob Lacouture)
I have a much better solution here: https://github.com/ruby/ruby/pull/15840 It's simpler than my original PR. It dispenses with the additional thread and the magic number (sleep time). And in addition to bringing multi-core perf into li...jpl-coconut (Jacob Lacouture)
I created a PR with my original changes applied to master. It's [here](https://github.com/ruby/ruby/pull/15294). The proposal to use a single-thread per process rather than one per ractor involves some complexity, but I think it's sim...jpl-coconut (Jacob Lacouture)
While debugging a performance issue in a large rails application, I wrote a minimal microbenchmark that reproduces the issue. [[here]](https://gist.github.com/jpl-coconut/cb3679ce885eb578e1071c4b3a525d5c) I was surprised to see that the ...jpl-coconut (Jacob Lacouture)