[#101179] Spectre Mitigations — Amel <amel.smajic@...>
Hi there!
5 messages
2020/12/01
[#101180] Re: Spectre Mitigations
— Chris Seaton <chris@...>
2020/12/01
I wouldn’t recommend using Ruby to run in-process untrusted code in the first place. Are people doing that?
[#101694] Ruby 3.0.0 Released — "NARUSE, Yui" <naruse@...>
We are pleased to announce the release of Ruby 3.0.0. From 2015 we
4 messages
2020/12/25
[ruby-core:101592] [Ruby master Feature#17414] Ractor should allow access to shareable attributes for Modules/Classes
From:
eregontp@...
Date:
2020-12-21 15:56:40 UTC
List:
ruby-core #101592
Issue #17414 has been updated by Eregon (Benoit Daloze).
marcandre (Marc-Andre Lafortune) wrote in #note-2:
> Using `yaml/psych` should be doable easily in multiple Ractors, right?
Ideally, but I guess there might be many issues with existing gems and the restrictions of Ractor.
> Having the global config be per-Ractor would complicate the design for no gain.
It depends what you do with Ractor. If it was hosting multiple apps in the same process, it might make a lot of sense.
> At any point in time, the global config [...]
I think Ractor compatibility is a good opportunity to actually revisit whether things need to be global.
In many (all?) cases, it does not need to be global.
For instance, such domain specific handlers could be passed explicitly to YAML.load/dump, which would be much clearer and cleaner.
----------------------------------------
Feature #17414: Ractor should allow access to shareable attributes for Modules/Classes
https://bugs.ruby-lang.org/issues/17414#change-89378
* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
Current situation is *very* limiting.
Use-case: global config.
Example: [yaml has a global config](https://github.com/ruby/psych/blob/master/lib/psych.rb#L637-L640) and it's not clear to me how to make that Ractor-aware (nicely).
It is possible to have the same effect but in ugly ways:
```ruby
# Using instance variables of Module not allowed:
module Config
class << self
attr_accessor :conf
end
self.conf = 42
end
Ractor.new { Config.conf = 66 }.take # => can not access instance variables from non-main Ractors
Ractor.new { puts Config.conf }.take # => can not access instance variables from non-main Ractors
# Same functionality using constants allowed:
module Config
class << self
def conf
CONF
end
def conf=(new_conf)
remove_const(:CONF)
const_set(:CONF, new_conf)
end
end
CONF = 42
end
Ractor.new { Config.conf = 66 }.take # => ok
Ractor.new { puts Config.conf }.take # => 66
# Same functionality using methods allowed:
module Config
class << self
def conf
42
end
def conf=(new_conf)
singleton_class.undef_method(:conf)
define_singleton_method(:conf, &Ractor.make_shareable(Proc.new { new_conf }))
end
end
end
Ractor.new { Config.conf = 66 }.take # => ok
Ractor.new { puts Config.conf }.take # => 66
```
The priority would be to allow reading these instance variables if they are shareable. Ideally writing would also be allowed, but limiting that to main ractor is less probablematic than with reading.
--
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>