4 ms·

Reactor model. Nice. Very nice. So real ruby multithreading at last. Okay time to upgrade to latest rails and wait for the multithreaded rails release. :P

sosodev 6y ago
I suspect it will be quite a while before we see Ractor being used in Rails. Ractor is very strict about data isolation to prevent race conditions and existing code will need significant refactoring.
dorianmariefr 6y ago
puma, the default webserver when using rails, is most-likely what would be using ractors
- sosodev 6y ago
  Here's schneems, a Puma maintainer, talking about Ractor, Rails, and Puma https://old.reddit.com/r/ruby/comments/ivasiq/we_made_puma_faster_with_sleep_sort/g5qx59n/ https://old.reddit.com/r/ruby/comments/ivasiq/we_made_puma_f...
  - jacobvosmaer 6y ago
    >The biggest issue with ractor support as it stands today would really be getting ALL the libraries any given app uses to support the ractor design. I wonder if this will create a chicken-egg situation. Without significant Ractor adoption it will be hard to get libraries to adapt. Without essential pieces like Puma supporting (and benefiting from) Ractor there is less reason to for apps to use Ractor. I am reminded of the difficulties faced by Rubinius, which if I understand correctly, was hampered by too many MRI-compatible libraries not working to get people to switch.
    - sosodev 6y ago
      I imagine getting wide support for Ractor will be easier than Rubinius and other async Ruby attempts since it’s actually part of the core language.
joelbluminator 6y ago
I don't understand what you mean by "real multithreading". What I understand from Ractor is that it makes it safer to write concurrent code (e.g there are constructs that keep you from mutating shared data). But there is still a global VM lock, or is that gone in Ractor?
- lucraft 6y ago
  I believe the VM lock is now per-ractor, so no longer global no. Then there are constraints on what can be shared between ractors to ensure safety.

sosodev 6y ago

I suspect it will be quite a while before we see Ractor being used in Rails. Ractor is very strict about data isolation to prevent race conditions and existing code will need significant refactoring.

dorianmariefr 6y ago

puma, the default webserver when using rails, is most-likely what would be using ractors

sosodev 6y ago
Here's schneems, a Puma maintainer, talking about Ractor, Rails, and Puma https://old.reddit.com/r/ruby/comments/ivasiq/we_made_puma_faster_with_sleep_sort/g5qx59n/ https://old.reddit.com/r/ruby/comments/ivasiq/we_made_puma_f...
- jacobvosmaer 6y ago
  >The biggest issue with ractor support as it stands today would really be getting ALL the libraries any given app uses to support the ractor design. I wonder if this will create a chicken-egg situation. Without significant Ractor adoption it will be hard to get libraries to adapt. Without essential pieces like Puma supporting (and benefiting from) Ractor there is less reason to for apps to use Ractor. I am reminded of the difficulties faced by Rubinius, which if I understand correctly, was hampered by too many MRI-compatible libraries not working to get people to switch.
  - sosodev 6y ago
    I imagine getting wide support for Ractor will be easier than Rubinius and other async Ruby attempts since it’s actually part of the core language.

joelbluminator 6y ago

I don't understand what you mean by "real multithreading". What I understand from Ractor is that it makes it safer to write concurrent code (e.g there are constructs that keep you from mutating shared data). But there is still a global VM lock, or is that gone in Ractor?

lucraft 6y ago
I believe the VM lock is now per-ractor, so no longer global no. Then there are constraints on what can be shared between ractors to ensure safety.