Tl;dr The goal is to keep compatibility with Ruby 2. It introduces the concept of guilds and channels to send objects between guilds. The bullet points below are quoted from a couple of slides, the other text is mine:<p>* Guild has at least one thread (and a thread has at least one fiber)<p>* Threads in different guilds can run in parallel<p>* Threads in a same guild can not run in parallel because of GVL (or GGL: Giant Guild Lock)<p>A guild can't access the objects of other guilds.<p>About channels:<p>* We have Guild::Channel to communicate each other<p>* 2 communication methods<p>1. Copy<p>2. Transfer membership or Move in short<p>Copy is a deep copy and the object is duplicated into the destination guild. A transfer removes an object from a guild and makes it available to another.<p>There are also immutable objects that are available to all guilds. An obvious example are numbers, which are objects in Ruby, booleans and symbols. I think that other objects are frozen with <a href="https://ruby-doc.org/core-2.3.1/Object.html#method-i-freeze" rel="nofollow">https://ruby-doc.org/core-2.3.1/Object.html#method-i-freeze</a><p>They already did some encouraging benchmarks.
Could you link to <a href="http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf" rel="nofollow">http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf</a> ? current one is on temporary file space (will be removed soon).
I worked on a similar proposal during my PhD thesis. It is formalized for a Java-like language and implemented in the Jikes RVM. We also carried a proof of isolation using Coq.<p><a href="https://tel.archives-ouvertes.fr/tel-00933072" rel="nofollow">https://tel.archives-ouvertes.fr/tel-00933072</a>
The key points IMHO:<p>1. This Ruby 3 proposal says that Ruby 2 compatibility is mission critical, therefore this proposal rejects concurrency solutions from other languages (e.g. Erlang) and concepts (e.g. functions) and data structures (e.g. immutable collections).<p>2 Instead the proposal is to create a fast copy-on-write with rules to "deep freeze" some kinds of objects and primitives into an immutable sharable state.
Hmm, I am wondering how moving ownership would work in a GC'ed system. You could have arbitrarily many references to the moved object (or subobjects). The slides say that an exception is thrown if an object of a different guild is accessed, but doesn't that mean that Ruby needs to check the guild at every object access?<p>Transfering ownership would probably also mean that Ruby not only needs to move one object but probably all subobjects recursively as well. I assume here that "moving" just means updating the guild field for each object.<p>Is this really feasible or wouldn't just copying the object be faster... I don't know of any system with gc that uses moving to transfer mutable objects between threads. Do such systems exist? Are there better ways of implementing this?
How would you use this to parallelize Rails requests? I guess you would need a pool of guilds, each with its own set of controllers, etc.<p>Since the requests would not be in the "main" guild, it might be painful to call into gems.
Ok, "guilds"? Is the principle behind this so much different than everything done before that it requires repurposing a completely new word?<p>On par with That's "crates". Gives the impression some people just want to be remembered as inventing names.
If I'm reading this proposal correctly, locks will still be needed within multithreaded guilds to guard mutations against complex object graphs.<p>Here's my reasoning. Since the GVL is insufficient to guard against data races on Ruby 2, under the guild system, locks would be needed to guard against concurrency issues if multiple threads are present.<p>It would seem like the intention would be to replace usages of Thread with Guild to avoid the concurrency issues inherent with threaded code. Will there be API support to create a Guild that only allows a single thread?
This is interesting. It doesn't mention GC, but since frozen objects can be shared between guilds, I assume the GC remains global. Perhaps this will trigger interest in immutable datastructures in ruby.
How does this compare to the ongoing efforts to remove the GIL in Python? It looks like the Ruby GVL would stay, but be scoped to a Guild, rather than a Process?
This reminds me in some ways of Eric Snow's (rejected, afaik) proposal to extend "subinterpreters" to allow parallelism in Python.<p><a href="https://lwn.net/Articles/650489/" rel="nofollow">https://lwn.net/Articles/650489/</a>