January 2026 - ruby-core - ml.ruby-lang.org

[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: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

[ruby-core:124509] [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). BTW `#num_waiting` is always tricky to implement so if we add new classes I would like to not have that, because it's always messy to implement and makes it e.g. impossible to reuse JDK classes for JRuby & TruffleRuby. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116069 * 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:124508] [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). From a quick look the closest thing to a concurrent Stack in Java is [LinkedBlockingDeque](https://docs.oracle.com/en/java/javase/25/docs/api/jav…. That implementation uses a single lock and condition variables, so it's not particularly efficient and likely causes significant contention. In comparison [LinkedBlockingQueue](https://docs.oracle.com/en/java/javase/25/docs/api/jav… uses two locks (basically one for push, one for pop) to avoid contention, unless the queue is completely empty and then both locks need to be taken. That illustrates my point that having a `Deque` limits the implementation choices and optimizations significantly. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116068 * 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:124507] [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). ko1 (Koichi Sasada) wrote in #note-4: > * If we assume the implementation of `Queue` is based on `Dequeu`, adding `pop_back()` (LIFO operation) seems reasonalbe, and easy to introduce than introducing new classes, and good aligned to Ruby's large-class philosophy. I want to ask Matz again. This would make the implementation of Queue (based on Deque or not) far more complicated and less efficient, as I said in the last paragraph of https://bugs.ruby-lang.org/issues/21721#note-2. I think we should either: * Add nothing because this is not a common need and there are 2 reasonable alternatives: https://bugs.ruby-lang.org/issues/21721#note-2 and https://bugs.ruby-lang.org/issues/21721#note-18 * Add Thread::Stack & Thread::SizedStack. I think it's not good to alias them in `Object` because they should not be used if the stack is used by a single Thread, Array should be used instead. > I'm afraid that expanding the similar idea like `Thread::Heap`, `Thread::PriorityQueue` and so on, atomic containers for each data structure. Yes, it starts to feel like Java. I think there are not enough use cases for concurrent stacks to deserve to be core. It could be in concurrent-ruby perhaps, or maybe the 2 alternatives linked above are good enough. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116067 * 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:124506] [Ruby Feature#21821] Add Stack and SizedStack classes
by ko1 (Koichi Sasada) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by ko1 (Koichi Sasada). I heard that C++ has deque: Double-Ended Queue https://en.cppreference.com/w/cpp/container/deque.html * The sound of `Deque` is similar to `dequeue` or `deq` (operation names). so introducing `Dequeue` seems not good idea. * If we assume the implementation of `Queue` is based on `Dequeu`, adding `pop_back()` (LIFO operation) seems reasonalbe, and easy to introduce than introducing new classes, and good aligned to Ruby's large-class philosophy. I want to ask Matz again. I'm afraid that expanding the similar idea like `Thread::Heap`, `Thread::PriorityQueue` and so on, atomic containers for each data structure. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116066 * 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:124479] [Ruby Misc#21834] Extract `yaml/store` into it's own gem that depends on the `pstore` gem
by postmodern (Hal Brodigan) 13 Jan '26

13 Jan '26

Issue #21834 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Misc #21834: Extract `yaml/store` into it's own gem that depends on the `pstore` gem https://bugs.ruby-lang.org/issues/21834 * Author: postmodern (Hal Brodigan) * Status: Open ---------------------------------------- Ruby 4.0.0 removed the `pstore` gem from the set of default stdlib libraries. However, `yaml/store` is still available from the `yaml` library, but relies on the `pstore` gem which is now no longer part of stdlib. It is odd that a file which is still part of stdlib requires another gem that is not part of stdlib. Perhaps `yaml/store` could be extracted into it's own gem called `yaml-store` which would have an explicit dependency on the `pstore` gem. This would reduce the need to explicitly list `pstore` as a gem dependency in the `Gemfile` or gemspec, if code requires `yaml/store` for `YAML::Store`. -- https://bugs.ruby-lang.org/

2 2