Issue #19387 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Closed Re-checked on master 4d185cce78: this no longer reproduces. With per-Ractor GC (GH-18194) each Ractor has its own objspace, and `ObjectSpace.each_object` walks the calling Ractor's objspace directly, so it keeps working while other Ractors are alive: port = Ractor::Port.new r = Ractor.new(port) { |p| p << :up; Ractor.receive } port.receive p ObjectSpace.each_object(IO).count ruby 4.0.2 : 0 master : 3 Isolation is still respected. Letting a sub-Ractor build one unshareable and one shareable String and scanning for them from the main Ractor: 4.0.2 master own unshareable objects no yes another Ractor's unshareable objects no no another Ractor's shareable objects yes yes (the last row needs the object to have actually been made shareable; a merely frozen String that nobody has shared yet does not carry the flag and is not enumerated.) So the reported symptom -- `each_object` yields nothing once a Ractor has been started -- is gone, and `Ractor.new` can be used in `make test-all` again. One follow-up: the documentation added in GH-13278 ("Due to a current Ractor implementation issue, this method does not yield Ractor-unshareable objects when the process is in multi-Ractor mode", which links to this ticket) is now wrong. I will send a separate PR for it. ---------------------------------------- Bug #19387: ObjectSpace.each_objects only returns shareable objects after starting a Ractor https://bugs.ruby-lang.org/issues/19387#change-118831 * Author: luke-gru (Luke Gruber) * Status: Closed * Assignee: ractor * ruby -v: 3.3.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do receive # block, the problem is not the termination of the ractor but the starting end ObjectSpace.each_object(IO) { |io| p io # we get no objects } ``` -- https://bugs.ruby-lang.org/