- ruby-core - ml.ruby-lang.org

[ruby-core:124519] [Ruby Feature#21837] Introduce socket hooks in Fiber Scheduler interface
by noteflakes (Sharon Rosner) 13 Jan '26

13 Jan '26

Issue #21837 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21837: Introduce socket hooks in Fiber Scheduler interface https://bugs.ruby-lang.org/issues/21837 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- Currently the fiber scheduler interface does not support any socket operations. The stock Ruby socket implementation performs all operations in a non-blocking way, and invokes the `#io_wait` fiber scheduler hook in order to wait for readiness. I propose adding the following hooks: - `#socket_recv(sock, buffer, length, flags, recvfrom)`: performs a `recv` or `recvfrom`. The `recvfrom` argument is a boolean denoting whether a `recvfrom` should be performed. When true, the hook should return an array containing the number of bytes received and the source address. When false, the hook should return the number of bytes received. - `#socket_send(sock, dest, buffer, length, flags)`: performs a `send` or `sendto`. The `dest` argument is nil for a `send`. When not nil, a `sendto` operation should be done. - `#socket_connect(sock, addr)`: performs a `connect`. - `#socket_accept(sock, client_sockaddr)` - performs an `accept`. The `client_sockaddr` argument is an `IO::Buffer` that receives the peer addrinfo. The PR for this feature: https://github.com/ruby/ruby/pull/15865 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124518] [Ruby Bug#21836] RUBY_MN_THREADS deadlock and sleep issues
by jpl-coconut (Jacob Lacouture) 13 Jan '26

13 Jan '26

Issue #21836 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21836: RUBY_MN_THREADS deadlock and sleep issues https://bugs.ruby-lang.org/issues/21836 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-11-08) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- 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 just a bit over 10 seconds, regardless of how many cores or threads are assigned. It should look like this: ``` > time taskset --cpu-list 1 ./ruby 100usec.rb 1 real 0m10.130s user 0m0.094s sys 0m0.218s ``` It works fine with MN_THREADS disabled. However, with RUBY_MN_THREADS=1, I see two separate issues. ### Issue #1 is that when the number of cores is set to more than 1, the benchmark completes too fast. These results are consistent across the ruby versions I tried. I did a little debugging and found that the call to `sleep(0.001)` (1ms) is returning after only 0.000005 seconds (5us). ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1,2 ./ruby 100usec.rb 1 real 0m0.359s user 0m0.075s sys 0m0.134s ``` ### Issue #2 shows up when the number of cores is limited to 1. - On ruby 3.4.7 it runs very slow, about 6x slower than expected. ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1 ./ruby 100usec.rb 1 real 1m2.277s user 0m0.249s sys 0m0.408s ``` - On ruby 4.0.0-preview2 it usually deadlocks, but sometimes it segfaults. ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1 ./ruby ruby/100usec.rb 1 [BUG] unreachable ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +MN +PRISM [aarch64-linux] -- Control frame information ----------------------------------------------- -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- [BUG] Illegal instruction at 0x0000ffff93777250 ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +MN +PRISM [aarch64-linux] Crashed while printing bug report Illegal instruction ``` or ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1 ./ruby ruby/100usec.rb 1 <<DEADLOCK>> ``` ### The benchmark code (100usec.rb) ``` ruby ITRCOUNT = 10000 def inner_test r, w = IO.pipe reader = Thread.new do ITRCOUNT.times.map {|i| r.getbyte } end ITRCOUNT.times.map {|i| sleep 0.0001 w.write('0') } reader.join end def outer_test(count) count.times.map{|j| Thread.new do inner_test end }.each{|t| t.join} end outer_test(ARGV[0].to_i) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124475] [Ruby Bug#21832] segfault with argument forwarding, when combined with splat & positional arg
by inopinatus (Joshua GOODALL) 13 Jan '26

13 Jan '26

Issue #21832 has been reported by inopinatus (Joshua GOODALL). ---------------------------------------- Bug #21832: segfault with argument forwarding, when combined with splat & positional arg https://bugs.ruby-lang.org/issues/21832 * Author: inopinatus (Joshua GOODALL) * Status: Open * ruby -v: ruby 4.1.0dev (2026-01-11T15:46:56Z master 61c372a1b7) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A crash occurs when combining (...) arg forwarding, a positional argument, and an array splat. Found with 4.0.0 release, verified on 3.4.8 and 4.1.0dev, does not occur on 3.3.10. One-line crash test: ``` ruby ./ruby -e 'def target(*args) = args; def x = [1]; def forwarder(...); target(*x, 2, ...); end; forwarder(3)' ``` test builds were: * Ruby 4.1.0dev w/clang-1700.6.3.2 on arm64 (macOS Sequoia 15.7.1) * Ruby 3.4.8 w/gcc 13.3.0 on x86_64 (Ubuntu 24.04 LTS) longer test case: ``` ruby class Test def stdargs %w(--verbose) end def func(*args) puts "args: #{args.inspect}" end def test1(...) func("abc", ...) end def test2(...) func(stdargs, "abc", ...) end def test3(...) func(*stdargs, "abc") end def test4(...) func(*stdargs, ...) end def test5(...) func(*stdargs, "abc", ...) end end o = Test.new o.test1("T1") #=> args: ["abc", "T1"] o.test2("T2") #=> args: [["foo"], "abc", "T2"] o.test3("T3") #=> args: ["foo", "abc"] o.test4("T4") #=> args: ["foo", "T4"] o.test5("T5") #=> Expected: ["foo", "abc", "T5"] Actual: crash ``` Crash output: ``` [505] (master) joshua@coltrane:~/src/ruby-src$ ./ruby crash.rb `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. args: ["abc", "T1"] args: [["--verbose"], "abc", "T2"] args: ["--verbose", "abc"] args: ["--verbose", "T4"] crash.rb:28: [BUG] Segmentation fault at 0x0000000000000000 ruby 4.1.0dev (2026-01-11T15:46:56Z master 61c372a1b7) +PRISM [arm64-darwin24] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0003 p:0013 s:0017 e:000012 l:y b:0001 METHOD crash.rb:28 c:0002 p:0059 s:0007 E:002508 l:n b:---- EVAL crash.rb:38 [FINISH] c:0001 p:0000 s:0003 E:000010 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- crash.rb:38:in '<main>' crash.rb:28:in 'test5' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000160028078 x1: 0x0000000000000000 x2: 0x0000000000000010 x3: 0x0000000160028078 x4: 0x0000000000000000 x5: 0x000000016d97a670 x6: 0x000000016d97a648 x7: 0x000000016d97a598 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x000000016d97a648 x21: 0x0000000102e9da38 x22: 0x0000000160127f58 x23: 0x000000016d97a670 x24: 0x0000000160028078 x25: 0x000092d100100003 x26: 0x0000000160028060 x27: 0x0000000000000001 x28: 0x0000000000000001 lr: 0x00000001026eab50 fp: 0x000000016d97a5e0 sp: 0x000000016d97a560 -- C level backtrace information ------------------------------------------- /Users/joshua/src/ruby-src/ruby(rb_vm_bugreport+0xbc8) [0x10271b60c] /Users/joshua/src/ruby-src/vm_dump.c:1450 /Users/joshua/src/ruby-src/ruby(rb_vm_bugreport) (null):0 /Users/joshua/src/ruby-src/ruby(rb_bug_for_fatal_signal+0x10c) [0x10254092c] /Users/joshua/src/ruby-src/error.c:1131 /Users/joshua/src/ruby-src/ruby(sigsegv+0x90) [0x102671e70] /Users/joshua/src/ruby-src/signal.c:948 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x196be16a4] /Users/joshua/src/ruby-src/ruby(RB_FL_TEST_RAW+0x0) [0x1026eab50] ./include/ruby/internal/memory.h:759 /Users/joshua/src/ruby-src/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:466 /Users/joshua/src/ruby-src/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:259 /Users/joshua/src/ruby-src/ruby(vm_caller_setup_fwd_args) ./vm_insnhelper.c:3410 /Users/joshua/src/ruby-src/ruby(vm_exec_core+0x12f0) [0x1026ed304] /Users/joshua/src/ruby-src/insns.def:877 /Users/joshua/src/ruby-src/ruby(rb_vm_exec+0x284) [0x1026ea428] /Users/joshua/src/ruby-src/vm.c:2798 /Users/joshua/src/ruby-src/ruby(rb_ec_exec_node+0x8c) [0x10254bb84] /Users/joshua/src/ruby-src/eval.c:283 /Users/joshua/src/ruby-src/ruby(ruby_run_node+0x4c) [0x10254baa4] /Users/joshua/src/ruby-src/eval.c:321 /Users/joshua/src/ruby-src/ruby(rb_main+0x1c) [0x102484980] ./main.c:42 /Users/joshua/src/ruby-src/ruby(main) ./main.c:62 ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:124516] [Ruby Feature#21821] Add Stack and SizedStack classes
by p8 (Petrik de Heus) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by p8 (Petrik de Heus). Eregon (Benoit Daloze) wrote in #note-9: > It reminds me when I once tried to replace the queue in Puma's [thread pool](https://github.com/puma/puma/blob/main/lib/puma/thread_pool.rb) with a SizedQueue to remove the extra ConditionVariable & Mutex, but it's not possible, it does things that SizedQueue can't do. The ConditionVariable in Puma 7's thread pool is causing issues in JRuby: https://github.com/jruby/jruby/issues/9140 Sequel's [timed_queue](https://github.com/jeremyevans/sequel/blob/4293be3cb8dbb50992e… avoids the ConditionalVariable with [big improvements for some](https://github.com/jeremyevans/sequel/discussions/2207), but I'm not sure that can be applied to Puma. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116076 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124478] [Ruby Misc#21833] Switch default hash from SipHash13 to XXH3?
by samyron (Scott Myron) 13 Jan '26

13 Jan '26

Issue #21833 has been reported by samyron (Scott Myron). ---------------------------------------- Misc #21833: Switch default hash from SipHash13 to XXH3? https://bugs.ruby-lang.org/issues/21833 * Author: samyron (Scott Myron) * Status: Open ---------------------------------------- Has there been any consideration switching to some other hash implementation? I've searched through the issues and haven't found anything related to switching the default hash from SipHash13 to anything else. I created a [branch](https://github.com/ruby/ruby/compare/master...samyron:ruby:sm/xxh3) which switched `rb_memhash` from SipHash13 to [XXH3](https://github.com/Cyan4973/xxHash). I created a few simple benchmarks and ran them on my M1 Macbook Air. The results are very promising. ``` % cat ~/string_hash.yml prelude: | # Generate sets of short vs medium strings TINY_STRINGS = Array.new(100) { Array.new(3).map { (97 + rand(26)).chr }.join }.freeze SMALL_STRINGS = Array.new(100) { Array.new(8).map { (97 + rand(26)).chr }.join }.freeze MED_STRINGS = Array.new(100) { Array.new(20).map { (97 + rand(26)).chr }.join }.freeze LARGE_STRINGS = Array.new(100) { Array.new(200).map { (97 + rand(26)).chr }.join }.freeze HUGE_STRINGS = Array.new(100) { Array.new(65536).map { (97 + rand(26)).chr }.join }.freeze benchmark: tiny_strings: | TINY_STRINGS.each { |s| s.hash } small_strings: | SMALL_STRINGS.each { |s| s.hash } medium_strings: | MED_STRINGS.each { |s| s.hash } large_strings: | LARGE_STRINGS.each { |s| s.hash } huge_strings: | HUGE_STRINGS.each { |s| s.hash % benchmark-driver ~/string_hash.yml \ -e ruby-master::~/.rubies/ruby-master/bin/ruby \ -e ruby-xxhash::~/.rubies/ruby-xxhash/bin/ruby \ --output compare Warming up -------------------------------------- tiny_strings 262.513k i/s - 283.844k times in 1.081258s (3.81μs/i) small_strings 259.803k i/s - 280.445k times in 1.079454s (3.85μs/i) medium_strings 249.553k i/s - 267.531k times in 1.072041s (4.01μs/i) large_strings 116.426k i/s - 126.005k times in 1.082275s (8.59μs/i) huge_strings 498.481 i/s - 500.000 times in 1.003047s (2.01ms/i) Calculating ------------------------------------- ruby-master ruby-xxhash tiny_strings 264.070k 288.960k i/s - 787.538k times in 2.982305s 2.725421s small_strings 259.941k 286.229k i/s - 779.407k times in 2.998394s 2.723019s medium_strings 249.249k 283.952k i/s - 748.658k times in 3.003655s 2.636561s large_strings 116.572k 240.823k i/s - 349.278k times in 2.996244s 1.450351s huge_strings 500.164 5.296k i/s - 1.495k times in 2.989019s 0.282263s Comparison: tiny_strings ruby-xxhash: 288960.1 i/s ruby-master: 264070.2 i/s - 1.09x slower small_strings ruby-xxhash: 286229.0 i/s ruby-master: 259941.5 i/s - 1.10x slower medium_strings ruby-xxhash: 283952.5 i/s ruby-master: 249249.0 i/s - 1.14x slower large_strings ruby-xxhash: 240823.1 i/s ruby-master: 116571.9 i/s - 2.07x slower huge_strings ruby-xxhash: 5296.5 i/s ruby-master: 500.2 i/s - 10.59x slower ``` Running something a bit more real-world: ``` % cat ~/json_parse.yml prelude: | require 'json' activitypub_json_txt = File.read("/Users/scott/Development/json/benchmark/data/activitypub.json") twitter_json_txt = File.read("/Users/scott/Development/json/benchmark/data/twitter.json") citm_catalog_json_txt = File.read("/Users/scott/Development/json/benchmark/data/citm_catalog.json") ohai_json_txt = File.read("/Users/scott/Development/json/benchmark/data/ohai.json") benchmark: parse_activitypub_json: | JSON.parse(activitypub_json_txt) parse_twitter_json_txt: | JSON.parse(twitter_json_txt) parse_citm_catalog_json_txt: | JSON.parse(citm_catalog_json_txt) parse_ohai_json_txt: | JSON.parse(ohai_json_txt) % benchmark-driver ~/json_parse.yml \ -e ruby-master::~/.rubies/ruby-master/bin/ruby \ -e ruby-xxhash::~/.rubies/ruby-xxhash/bin/ruby \ --output compare Warming up -------------------------------------- parse_activitypub_json 10.969k i/s - 12.023k times in 1.096043s (91.16μs/i) parse_twitter_json_txt 1.169k i/s - 1.265k times in 1.082330s (855.60μs/i) parse_citm_catalog_json_txt 591.782 i/s - 600.000 times in 1.013887s (1.69ms/i) parse_ohai_json_txt 12.000k i/s - 12.782k times in 1.065168s (83.33μs/i) Calculating ------------------------------------- ruby-master ruby-xxhash parse_activitypub_json 10.986k 11.071k i/s - 32.908k times in 2.995440s 2.972542s parse_twitter_json_txt 1.162k 1.172k i/s - 3.506k times in 3.016331s 2.991486s parse_citm_catalog_json_txt 588.758 601.926 i/s - 1.775k times in 3.014820s 2.948868s parse_ohai_json_txt 10.747k 12.400k i/s - 35.999k times in 3.349753s 2.903138s Comparison: parse_activitypub_json ruby-xxhash: 11070.7 i/s ruby-master: 10986.0 i/s - 1.01x slower parse_twitter_json_txt ruby-xxhash: 1172.0 i/s ruby-master: 1162.3 i/s - 1.01x slower parse_citm_catalog_json_txt ruby-xxhash: 601.9 i/s ruby-master: 588.8 i/s - 1.02x slower parse_ohai_json_txt ruby-xxhash: 12400.0 i/s ruby-master: 10746.8 i/s - 1.15x slower ``` Admittedly, I'm not a hash expert nor a cryptographer. There doesn't seem to be any known vulnerabilities with XXH3 that I have found. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:124288] [Ruby Bug#21790] `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts
by adamoffat (Adam Moffat) 13 Jan '26

13 Jan '26

Issue #21790 has been reported by adamoffat (Adam Moffat). ---------------------------------------- Bug #21790: `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts https://bugs.ruby-lang.org/issues/21790 * Author: adamoffat (Adam Moffat) * Status: Open * ruby -v: 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby's `Socket.getaddrinfo` hangs indefinitely in forked child processes on macOS 26.1 (Tahoe) when resolving IPv4-only hostnames. This is a regression that does not occur on macOS 15.x (Sonoma) or earlier. **Ruby version:** ruby 3.3.8 (2025-04-09 revision b200bad6cd) [arm64-darwin24] Also confirmed this affects Ruby 3.2.6 and 3.4.1. **Reproducible script:** ``` ruby require "socket" require "timeout" puts "Ruby #{RUBY_VERSION} on #{RUBY_PLATFORM}" Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) puts "Parent: DNS completed" pid = fork do puts "Child: Attempting DNS resolution..." begin Timeout.timeout(90) do Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) end puts "Child: SUCCESS" exit 0 rescue Timeout::Error puts "Child: FAILED - hung for 90 seconds" exit 1 end end Process.wait(pid) ``` **Note:** Remove the `Timeout.timeout(90)` wrapper to observe the hang indefinitely. The timeout is included only to allow the script to exit for testing purposes. **Result of reproduce process:** ``` Ruby 3.3.8 on arm64-darwin24 Parent: DNS completed Child: Attempting DNS resolution... Child: FAILED - hung for 90 seconds ``` The child process hangs with one thread consuming 100% CPU. Expected result: The child process should complete DNS resolution successfully, as it does on macOS 15.x and earlier. **Analysis:** Stack trace shows: Main thread: Blocked in `wait_getaddrinfo` → `_pthread_cond_wait` DNS thread: Spinning in `_gai_nat64_second_pass` → `nw_path_access_agent_cache` → `_os_log_preferences_refresh` → `SIGSEGV` The crash occurs in macOS's NAT64 synthesis code path. Ruby's signal handler catches the `SIGSEGV` but cannot recover, causing the DNS thread to spin. **Key observations:** - Only affects IPv4-only hosts. Hosts with IPv6 (like google.com) work correctly. - Using `AF_INET` instead of `AF_UNSPEC` works. `Socket.getaddrinfo("api.segment.io", 443, Socket::AF_INET, :STREAM)` succeeds. - Python is not affected. Python calls `getaddrinfo()` synchronously without a background thread. - Parent must do DNS before fork. If the parent has not called getaddrinfo(), the child works correctly. **Workaround:** - Use `resolv-replace` to bypass the native DNS resolver: `require "resolv-replace"` **Impact:** This breaks all Ruby applications using pre-forking worker models (Resque, Unicorn, Puma, Sidekiq, Passenger) on macOS Tahoe. **Apple Bug Report:** Filed with Apple as Feedback Assistant #FB21364061 ---Files-------------------------------- stack_trace.txt (66.6 KB) ruby_dns_fork_bug.rb (1.02 KB) -- https://bugs.ruby-lang.org/

2 8

[ruby-core:124513] [Ruby Feature#21821] Add Stack and SizedStack classes
by byroot (Jean Boussier) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by byroot (Jean Boussier). > IOW, I think we should have performance numbers here and implemented use cases that pass the relevant test suites Yes that's fair. I meant to re-implement the `redis-client` pool using `Thread::Queue` as a proof of concept, but didn't get around to it yet. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116073 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124512] [Ruby Feature#21821] Add Stack and SizedStack classes
by Eregon (Benoit Daloze) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by Eregon (Benoit Daloze). byroot (Jean Boussier) wrote in #note-8: > About the second one, it's clever but not sure if ideal because it's no longer "atomic" on MRI, so is subject to `Thread#raise`. Looking at the `connection_pool` gem, one thing that slows it down considerably is the numerous calls to `Thread.handle_interrupt` to avoid leaking connections when `Timeout` is used. I see https://github.com/mperham/connection_pool/blob/f3645821d02fe8de5089f31b616… There is lots of code in checkin/checkout anyway, those `Thread.handle_interrupt` can't be removed even if SizedStack exists. Even if it's a single method call directly to a SizedStack method, that could still check interrupts, and it definitely would for `pop`, so you'd still need the `Thread.handle_interrupt`. On that topic maybe we should have all `ensure` automatically be `Thread.handle_interrupt(Object => :never)` (https://bugs.ruby-lang.org/issues/17849#note-5) or a way to opt-in per `ensure`. Also [ConnectionPool::TimedStack](https://github.com/mperham/connection_pool/blob… has a bunch of code which doesn't seem to me like it could be replaced or implemented with a SizedStack (but I haven't tried). It reminds me when I once tried to replace the queue in Puma's [thread pool](https://github.com/puma/puma/blob/main/lib/puma/thread_pool.rb) with a SizedQueue to remove the extra ConditionVariable & Mutex, but it's not possible, it does things that SizedQueue can't do. IOW, I think we should have performance numbers here and implemented use cases that pass the relevant test suites, otherwise we might add a class that actually can't be used for the intended use cases. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116072 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124511] [Ruby Feature#21821] Add Stack and SizedStack classes
by byroot (Jean Boussier) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by byroot (Jean Boussier). > there are 2 reasonable alternatives About the second one, it's clever but not sure if ideal because it's no longer "atomic" on MRI, so is subject to `Thread#raise`. Looking at the `connection_pool` gem, one thing that slows it down considerably is the numerous calls to `Thread.handle_interrupt` to avoid leaking connections when `Timeout` is used. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116071 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123878] [Ruby Bug#21702] `UNIXSocket` on Windows: suprising results in `#recvfrom` and `#remote_address`
by trinistr (Alexander Bulancov) 13 Jan '26

13 Jan '26

Issue #21702 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21702: `UNIXSocket` on Windows: suprising results in `#recvfrom` and `#remote_address` https://bugs.ruby-lang.org/issues/21702 * Author: trinistr (Alexander Bulancov) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Support for `UNIXSocket` on Windows was added in #19135. Through testing in ruby/spec, I identified unexpected results in two methods: 1. `#remote_address.to_s` always returns 110 bytes, compared to `#local_address.to_s` which returns only needed bytes. Example: ```ruby # test (@addr is remote_address, @b is the socket created with UNIXServer#accept): @addr.to_s.should == @b.local_address.to_s # failure: "\x01\x00D:/a/spec/spec/rubyspec_temp/2032_3/unix.sock\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" == "\x01\x00D:/a/spec/spec/rubyspec_temp/2032_3/unix.sock\x00" ``` Note how the address is correct, and `#unix_path`s are indeed equal, but there are NUL bytes filling the string representation up to 110 bytes. This number does not depend on the length of path name. 2. Much more worryingly, `UNIXSocket#recvfrom` **dumps 2047 bytes of memory** as the remote address: ```ruby # test: @server.recvfrom(5).should == ['hello', ['AF_UNIX', '']] # failure: ["hello",["AF_UNIX","\x14\xB3v\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x00\xAB\xCD\x12C\xFF\x7F<snip>"]] == ["hello", ["AF_UNIX", ""]] ``` This seems to be a result of `union_sockaddr` having a `char place_holder[2048]` member inside, though it isn't clear why is this used instead of `sockaddr_un` member. These results are obtained from GitHub runners, as I don't have a machine to test directly. This is the PR in ruby/spec which brought this up: https://github.com/ruby/spec/pull/1300. -- https://bugs.ruby-lang.org/

3 4