A note to whoever backports this (which could be me, I'm just waiting ~ 1 week and checking various CIs after the merge): https://github.com/ruby/ruby/pull/16362 should be backported as well, they are really 1 fix in 2 separate commit...luke-gru (Luke Gruber)
I'm getting a segfault when running your minimal reproduction script on my Macbook Pro (`Darwin Mac 25.2.0 Darwin Kernel Version 25.2.0 (Apple Silicon)`). I get the segfault when compiling under all 3 `GETADDRINFO_IMPL` implementations ...luke-gru (Luke Gruber)
Thank you for the nice reproduction! We have a fix coming, and it will probably be backported to 3.3, 3.4 and 4.0. The fix is at https://github.com/ruby/ruby/pull/16307.luke-gru (Luke Gruber)
I wasn't aware of those old issues. I'll take a look, thanks! I reverted the commit because of issues with a `Monitor` test in CI. I thought it was related to this change, but the test kept failing even after the revert. It turns out it...luke-gru (Luke Gruber)
I'm confused about what should happen. Shouldn't it return roughly after 1 second instead of 10 seconds? I'll look into the sleep issue with `RUBY_MN_THREADS=1`, but I can't reproduce the deadlock or segfault with a more recent commit (a...luke-gru (Luke Gruber)
I did some benchmarking based on the updated solution (https://github.com/ruby/ruby/pull/15840). I've attached Puma benchmark results that I got using the PR from the previous post (d7ef5ecc9b) vs that PR's base commit (ad6b85450d). The ...luke-gru (Luke Gruber)
Hi, There's a problem with Ruby's scheduler that I want to solve. # The Problem Since Ruby schedules threads using round-robin inside a Ractor, threads doing I/O after only running for a short time are punished. Once the I/O fin...luke-gru (Luke Gruber)
Continually locking a mutex `m` can lead to starvation if all other threads are on the waitq of `m`. Let `T` be the thread that keeps on acquiring mutex `m` in a loop. Iteration 1: 1) `T` locks mutex `m` 2) All other threads at...luke-gru (Luke Gruber)