> Thanks, that makes sense. At the moment a locked buffer can be frozen, and #locked on a frozen buffer still increments lock_count, so I assume both will be handled as part of the implementation. Correct :)ioquatix (Samuel Williams)
> Even on a frozen buffer, #locked updates lock_count with a non-atomic read-modify-write, so two Ractors calling #locked on the same buffer would cause a data race on it. It seems that freezing alone is not sufficient for sharing. As p...ioquatix (Samuel Williams)
@matz ## Slices Implemented in https://github.com/ruby/ruby/pull/18911 ## Freeze > freezing to mean that the object's own state is immutable I agree with that. An `IO::Buffer`'s own state consists of: ```c struct rb_io...ioquatix (Samuel Williams)
@headius You're right - my bad — the isolation there is incidental, not a guarantee. If the frame is captured as a shared proc, threads race on it badly. But I think that actually restates my point rather than refuting it. There is no ...ioquatix (Samuel Williams)
@headius Just thinking out loud... > Switching your code to a fiber shouldn't suddenly make them disappear, or should it? I'd gently push back on this, because switching to a *thread* already does exactly that today, and has for...ioquatix (Samuel Williams)
@matz Fiber schedulers typically use `#transfer`, so preventing it would be problematic. There is also an assumption being made that it's desirable for `svars` to leak out of enumerators, which may not always be the case, e.g. ...ioquatix (Samuel Williams)
ioquatix (Samuel Williams)05:31 AM Ruby Feature #22274: Make `IO::Buffer` no longer experimental.