3 ms·

I thought the Global Interpreter Lock limited how effective concurrency could ever get in a single Ruby runtime (excepting maybe JRuby). My understanding was th

• byroot 4y ago
  > My understanding was that you could ever only get green threads. Ruby 1.8 had green threads, 1.9 onwards has native threads, but with a GVL. And 3.2 may have N:M threads. > Is the GIL not going to be a thing any more? On paper it's already done in 3.0. What used to be the GVL is now one lock per Ractor. Every object belongs to a Ractor, and the Ractor lock need to be acquired to access the objects, except for mutable objects that can be shared across ractors. So in practice if you are not spawning any more ractor than the main one the VM execute your program in, then it's technically still a global lock, but you now have (limited) ways to go around it.
• jbotdev 4y ago
  You can still use native threads, as long as you’re not expecting them to improve performance with multi-core CPU usage. The main purpose is typically to perform several I/O operations in parallel (e.g. multiple external API calls). That’s why Ruby applications often rely on “worker pools”, which are essentially forks, to scale performance across cores. Edit: as the sibling comment mentions, that’s part of what Ractor is trying to solve.