[#102652] [Ruby master Bug#17664] Behavior of sockets changed in Ruby 3.0 to non-blocking — ciconia@...
Issue #17664 has been reported by ciconia (Sharon Rosner).
23 messages
2021/02/28
[ruby-core:102370] [Ruby master Feature#17592] Ractor should allowing reading shareable class instance variables
From:
eregontp@...
Date:
2021-02-01 19:07:39 UTC
List:
ruby-core #102370
Issue #17592 has been updated by Eregon (Benoit Daloze).
Dan0042 (Daniel DeLorme) wrote in #note-9:
> That makes sense, but I'm curious about the implementation. I believe this requires synchronization of every access to a class instance variable?
I think essentially all accesses to mutable data on a module must have some form of synchronization, because they can be mutated from the main thread in parallel.
So I'd think it's already synchronized.
This is BTW one thing I dislike about Ractor: @ivar accesses depend on the receiver, if it's a module it's completely different than for all other objects, and requires synchronization.
But, that's already there, so might as well allow reading from other Ractors than being both inconsistent and inconvenient.
----------------------------------------
Feature #17592: Ractor should allowing reading shareable class instance variables
https://bugs.ruby-lang.org/issues/17592#change-90230
* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
It would be very helpful if Ractor was allowing reading class instance variables from non-main Ractor.
Currently is raises an IsolationError:
```ruby
module Foo
singleton_class.attr_accessor :config
Foo.config = {example: 42}.freeze
end
Ractor.new { p Foo.config } # => IsolationError
```
This limitation makes it challenging to have an efficient way to store general configs, i.e. global data that mutated a few times when resources get loaded but it immutable afterwards, and needs to be read all the time.
Currently the only way to do this is to use a constant and use `remove_const` + `const_set` (which can not be made atomic easily).
I think that allowing reading only may be the best solution to avoid any race condition, e.g. two different Ractors that call `@counter += 1`.
The only 3 scenarios I see here are:
0) declare the constant hack the official way to store config-style data
1) allow reading of instance variables for shareable objects (as long as the data is shareable)
2) allow read-write
I prefer 1)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>