Home/ Questions/Q 6049785
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T07:36:57+00:00

I’m trying to understand the difference between Ruby threads pre-1.9 and 1.9 (in the

  • 0

I’m trying to understand the difference between Ruby threads pre-1.9 and 1.9 (in the standard MRI implementation), but it seems that in terms of the benefits you can achieve with them, they’re practically the same. Is this correct?

From my limited understanding:

  • Pre-1.9 threads are “green threads”, which means that they’re managed by the Ruby interpreter, not the OS. One consequence of this is that you never achieve true concurrency, since you never have multiple threads running at the same time (even if you’re on a multicore/multiprocessor system). (However, you can get the appearance of concurrency, if execution switches between different threads, e.g., if some program runs while another is waiting on I/O.)
  • 1.9 threads are native threads, which means that they are indeed managed by the OS. If there were no global interpreter lock, this would allow Ruby to run multiple threads at the same time (on a multicore/multiprocessor system). But Ruby does have a global interpreter lock, which means that only one thread can ever be running, so again you don’t get true concurrency. (But you can still get the appearance of concurrency if execution switches between different threads.)

Is this correct, or am I missing something? What are the benefits of 1.9 threads vs. pre-1.9 threads (in MRI)?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I feel kind of silly offering this as an answer, but your description matches my understanding of the situation perfectly.

    If we are right, I should add that it does make sense to evolve the language this way.

    Keep in mind that a main point of functional programming, the Actor Model, and other shared-memory-alternative parallel models is to fix the extreme difficulty of developing a parallel shared-memory application. (“Threads considered harmful.”)

    So it would have been expecting way too much for Ruby to go from nothing-parallel to everything-parallel.

    The current approach seems to be to set up the mechanism but to keep the giant lock. I presume that in the future, individually debugged and tested functional areas will be allowed to execute in parallel as they receive fine-grain locks and concurrency testing.

    • 0