My example is just one way to crash the VM with `_id2ref`, I'm sure there are others. Eregon (Benoit Daloze) wrote in #note-7: > And we have in practice unique `object_id`s, so there is no collision in practice. In practice, yes, ...jhawthorn (John Hawthorn)
navidemad (Navid Emad) wrote: > On Ruby 4.0.x, `ObjectSpace._id2ref(id)` can return a **different, unrelated live object** instead of raising `RangeError`, after the object that owned the id has been garbage collected and its heap slot r...jhawthorn (John Hawthorn)
* [Bug #22216] Special variables (ex. Regexp backref and IO lastline) are thread-unsafe in some cases, incompatible with Ractor * Are we okay making this either thread-local or fiber-local? It's already Fiber-local at the top-level (o...jhawthorn (John Hawthorn)
Here's an example I think folks would expect to be thread safe, but fails on current CRuby after just a few iterations (thanks to the Thread.pass) ``` ruby def test_it proc { |str| str =~ /(.)(.)(.)/ Thread.pass # Commen...jhawthorn (John Hawthorn)
Just a note on the Ractor-incompatibility, I think that's actually a much smaller problem. We should only hit that via `Ractor.shareable_proc`, which is a point we can set svar as we want (or is a flag we could check for). We could fix t...jhawthorn (John Hawthorn)
I think I'm _somewhat_ sold on it being Fiber-local. There may be some incompatibilities, but the existing behaviour is already strange. Here's the first case I was worried about. If you get an Enumerator with lazy or an iterating metho...jhawthorn (John Hawthorn)