Issue #19387 has been reported by luke-gru (Luke Gruber).
----------------------------------------
Bug #19387: Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor
https://bugs.ruby-lang.org/issues/19387
* Author: luke-gru (Luke Gruber)
* Status: Open
* Priority: Normal
* 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/
Issue #19409 has been reported by luke-gru (Luke Gruber).
----------------------------------------
Bug #19409: Object's shape is reset after a ractor move
https://bugs.ruby-lang.org/issues/19409
* Author: luke-gru (Luke Gruber)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I believe an object should have the same shape after being moved from 1 ractor to another.
```ruby
class Obj
attr_accessor :a, :b, :c, :d
def initialize
@a = 1
@b = 2
@c = 3
end
end
r = Ractor.new do
obj = receive
#p RubyVM::Shape.of(obj)
obj.d = 4
p obj.a, obj.b, obj.c, obj.d # gets wrong values due to object shape id being reset on object
end
obj = Obj.new
#p RubyVM::Shape.of(obj)
r.send(obj, move: true)
r.take
```
--
https://bugs.ruby-lang.org/
Issue #19411 has been reported by luke-gru (Luke Gruber).
----------------------------------------
Bug #19411: GC issue with moved objects
https://bugs.ruby-lang.org/issues/19411
* Author: luke-gru (Luke Gruber)
* Status: Open
* Priority: Normal
* ruby -v: 3.2.0
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
This crashes:
```ruby
class Obj
def initialize
@obj = 3
end
end
GC.stress = true
r = Ractor.new do
obj = receive
p obj
end
obj = Obj.new
r.send(obj, move: true)
r.take
```
It only crashes with nested objects, if you remove the ivar set in `initialize` it works fine. Maybe missing `RB_GC_GUARD`?
--
https://bugs.ruby-lang.org/
Issue #19375 has been reported by luke-gru (Luke Gruber).
----------------------------------------
Bug #19375: File objects are currently shareable
https://bugs.ruby-lang.org/issues/19375
* Author: luke-gru (Luke Gruber)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I don't know the internals of file.c but I don't think files are thread-safe.
--
https://bugs.ruby-lang.org/
Issue #19333 has been reported by ioquatix (Samuel Williams).
----------------------------------------
Feature #19333: Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks.
https://bugs.ruby-lang.org/issues/19333
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
As it stands, Fiber Locals, Thread Locals and Fiber Storage have no way of deleting key-value associations.
```ruby
100.times do |i|
name = :"variable-#{i}"
Thread.current[name] = 10
end
```
Because of this, dynamically generated associations can leak over time. This is worse for things like Threads that might be pooled (or maybe an argument against user-space pooling).
In any case, having a way to delete those associations would allow application code to at least delete the associations when they no longer make sense.
I propose that assigning `nil` to "locals" or "storage" should effectively delete them.
e.g.
```ruby
100.times do |i|
name = :"variable-#{i}"
Thread.current[name] = 10
Thread.current[name] = nil # delete association
end
```
A more invasive alternative would be to define new interfaces like `Thread::Local`, `Fiber::Local` and `Fiber::Storage::Local` (or something) which correctly clean up on GC.
--
https://bugs.ruby-lang.org/
Issue #19442 has been reported by eightbitraptor (Matthew Valentine-House).
----------------------------------------
Bug #19442: Remove USE_RINCGC flag
https://bugs.ruby-lang.org/issues/19442
* Author: eightbitraptor (Matthew Valentine-House)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
[GitHub PR #7317](https://github.com/ruby/ruby/pull/7313)
Ruby doesn't compile when USE_RINCGC is disabled. It's also not being tested in CI. As @nobu has pointed out in comments on the PR, fixing it is simple.
I think there are 2 approaches we could take:
1. Remove `USE_RINCGC` entirely and always run with incremental GC enabled. We have a precedent for this: `USE_RGENGC=0` was removed [in this commit](https://github.com/ruby/ruby/commit/62c2b8c74e47652fc5bbaf6150f4acd… almost 3 years ago. `USE_RINCGC=0` is in a similar state. It has been broken for almost a year (since [this commit](https://github.com/ruby/ruby/commit/dde164e968e382d50b07ad455946888…), and [disabled in CI for more than 2 years](https://github.com/ruby/ruby/commit/46d3ea2c2569e2e5a9ee3e7e206f07f0….
2. We could fix `USE_RINCGC`. If we do this we should re-enable the CI task so that we continue to keep it working in the future.
I am very much in favour of option 1, because I don't think this flag is being actively used, and removing it will simplify the code and reduce the cognitive overhead of working with the GC. However I am happy to defer to the team here.
--
https://bugs.ruby-lang.org/
Issue #19324 has been reported by zverok (Victor Shepelev).
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I find `Enumerator.product` quite confusing, and can't find any justification in #18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method is not as popular (yet?) as I hoped, but still, two methods that do completely different things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse them unless you did a lot of math and "product" is firmly set for set product in your head).
I believe that EITHER of two problems would be concerning enough, but the combination of them seems to be a strong enough argument to make the change?.. (Maybe with graceful deprecation of module method in one next version, but, considering the Ruby 3.2 is just released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
Issue #19370 has been reported by zverok (Victor Shepelev).
----------------------------------------
Feature #19370: Anonymous parameters for blocks?
https://bugs.ruby-lang.org/issues/19370
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
Just to clarify: are anonymous parameters delegation is planned to support in blocks?
It would be a nice addition, if it is possible to implement:
```ruby
# data in form [request method, URL, params]:
[
[:get, 'https://google.com', {q: 'Ruby'}, {'User-Argent': 'Google-Chrome'}],
[:post, 'https://gist.github.com', 'body'],
# ...
].each { |method, *| request(method.to_s.upcase, *) }
```
...and at the very least, consistent with what the method definition can have.
If they are NOT planned to be implemented, I believe that at least error messages should be made much clearer, because currently, this would happen while running the code above:
> no anonymous rest parameter (SyntaxError)
I understand the reason (the `request` clause doesn't "see" anonymous parameter of the **block**, and claims that current **method** doesn't have them), but it looks honestly confusing and inconsistent.
--
https://bugs.ruby-lang.org/
Issue #19326 has been reported by sdwolfz (Codruț Gușoi).
----------------------------------------
Feature #19326: Please add a better API for passing a Proc to a Ractor
https://bugs.ruby-lang.org/issues/19326
* Author: sdwolfz (Codruț Gușoi)
* Status: Open
* Priority: Normal
----------------------------------------
Example 1:
```ruby
class Worker
def initialize(&block)
@block = block
end
def run
Ractor.new(@block, &:call)
end
end
worker = Worker.new { 1 }
puts worker.run.take
```
Errors with:
```
<internal:ractor>:271:in `new': allocator undefined for Proc (TypeError)
from scripts/run.rb:9:in `run'
from scripts/run.rb:14:in `<main>'
```
Example 2:
```ruby
class Worker
def initialize(&block)
@block = Ractor.make_shareable(block)
end
def run
Ractor.new(@block, &:call)
end
end
worker = Worker.new { 1 }
puts worker.run.take
```
Errors with:
```
<internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError)
from scripts/run.rb:5:in `initialize'
from scripts/run.rb:13:in `new'
from scripts/run.rb:13:in `<main>'
```
Example 3:
```ruby
class Worker
def initialize(&block)
@block = Ractor.make_shareable(block)
end
def run
Ractor.new(@block, &:call)
end
end
worker = Ractor.current.instance_eval { Worker.new { 1 } }
puts worker.run.take
```
Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker.
I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better.
The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter.
The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation).
--
https://bugs.ruby-lang.org/