window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster already exists') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() FORKING AND THREADING IN RUBY - The Codest
The Codest
  • About us
  • Services
    • Software Development
      • Frontend Development
      • Backend Development
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Data Engineers
      • Cloud Engineers
      • QA Engineers
      • Other
    • It Advisory
      • Audit & Consulting
  • Industries
    • Fintech & Banking
    • E-commerce
    • Adtech
    • Healthtech
    • Manufacturing
    • Logistics
    • Automotive
    • IOT
  • Value for
    • CEO
    • CTO
    • Delivery Manager
  • Our team
  • Case Studies
  • Know How
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
  • About us
  • Services
    • Software Development
      • Frontend Development
      • Backend Development
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Data Engineers
      • Cloud Engineers
      • QA Engineers
      • Other
    • It Advisory
      • Audit & Consulting
  • Value for
    • CEO
    • CTO
    • Delivery Manager
  • Our team
  • Case Studies
  • Know How
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
Back arrow GO BACK
2016-10-06
Software Development

FORKING AND THREADING IN RUBY

Marek Gierlach

As you probably know, Ruby has a few implementations, such as MRI, JRuby, Rubinius, Opal, RubyMotion etc., and each of them may use a different pattern of code execution. This article will focus on the first three of them and compare MRI

As you probably know, Ruby has a few implementations, such as MRI, JRuby, Rubinius, Opal, RubyMotion etc., and each of them may use a different pattern of code execution. This article will focus on the first three of them and compare MRI (currently the most popular implementation) with JRuby and Rubinius by running a few sample scripts which are supposed to assess suitability of forking and threading in various situations, such as processing CPU-intensive algorithms, copying files etc.Before you start “learning by doing”, you need to revise a few basic terms.

Fork

  • is a new child process (a copy of the parent one)
  • has a new process identifier (PID)
  • has separate memory*
  • communicates with others via inter-process communication (IPC) channels like message queues, files, sockets etc.
  • exists even when parent process ends
  • is a POSIX call – works mainly on Unix platforms

Thread

  • is “only” an execution context, working within a process
  • shares all of the memory with others (by default it uses less memory than a fork)
  • communicates with others by shared memory objects
  • dies with a process
  • introduces typical multi-threading problems such as starvation, deadlocks etc.

There are plenty of tools using forks and threads, which are being used on a daily basis, e.g. Unicorn (forks) and Puma (threads) on application servers level, Resque (forks) and Sidekiq (threads) on the background jobs level, etc.

The following table presents the support for forking and threading in the major Ruby implementations.

Ruby ImplementationForkingThreading
MRIYesYes (limited by GIL**)
JRuby–Yes
RubiniusYesYes

Two more magic words are coming back like a boomerang in this topic – parallelism and concurrency – we need to explain them a bit. First of all, these terms cannot be used interchangeably. In a nutshell – we can talk about the parallelism when two or more tasks are being processed at exactly the same time. The concurrency takes place when two or more tasks are being processed in overlapping time periods (not necessarily at the same time). Yes, it’s a broad explanation, but good enough to help you notice the difference and understand the rest of this article.

Fronented Report for 2020

The following table presents the support for parallelism and concurrency.

Ruby ImplementationParallelism (via forks)Parallelism (via threads)Concurrency
MRIYesNoYes
JRuby–YesYes
RubiniusYesYes (since version 2.X)Yes

That’s the end of the theory – let’s see it in practice!

  • Having separate memory doesn’t necessary cause consuming the same amount of it as the parent process. There are some memory optimization techniques. One of them is Copy on Write (CoW), which allows parent process to share allocated memory with child one without copying it. With CoW additional memory is needed only in the case of shared memory modification by a child process. In the Ruby context, not every implementation is CoW friendly, e.g. MRI supports it fully since the version 2.X. Before this version each fork consumed as much memory as a parent process.
  • One of the biggest advantages/disadvantages of MRI (strike out the inappropriate alternative) is the usage of GIL (Global Interpreter Lock). In a nutshell, this mechanism is responsible for synchronizing execution of threads, which means that only one thread can be executed at a time. But wait… Does it mean there is no point in using threads in MRI at all? The answer comes with the understanding of GIL internals… or at least taking a look at the code samples in this article.

Test Case

In order to present how forking and threading works in Ruby’s implementations, I created a simple class called Test and a few others inheriting from it. Each class has a different task to process. By default, every task runs four times in a loop. Also, every task runs against three types of code execution: sequential, with forks, and with threads. In addition, Benchmark.bmbm runs the block of code twice – first time in order to get the runtime environment up & running, the second time in order to measure. All of the results presented in this article were obtained in the second run. Of course, even bmbm method does not guarantee perfect isolation, but the differences between multiple code runs are insignificant.

require "benchmark"

class Test
  AMOUNT = 4

  def run
    Benchmark.bmbm do |b|
      b.report("sequential") { sequential }
      b.report("forking") { forking }
      b.report("threading") { threading }
    end
  end

  private

  def sequential
    AMOUNT.times { perform }
  end

  def forking
    AMOUNT.times do
      fork do
        perform
      end
    end

    Process.waitall
  rescue NotImplementedError => e
    # fork method is not available in JRuby
    puts e
  end

  def threading
    threads = []

    AMOUNT.times do
      threads << Thread.new do
        perform
      end
    end

    threads.map(&:join)
  end

  def perform
    raise "not implemented"
  end
end
Load Test

Runs calculations in a loop to generate big CPU load.

class LoadTest < Test
  def perform
    1000.times { 1000.times { 2**3**4 } }
  end
end

Let’s run it…

LoadTest.new.run

…and check the results

MRIJRubyRubinius
sequential1.8629282.0890001.918873
forking0.945018–1.178322
threading1.9139821.1070001.213315

As you can see, the results from sequential runs are similar. Of course there is a small difference between the solutions, but it’s caused by the underlying implementation of chosen methods in various interpreters.

Forking, in this example, has a significant performance gain (code runs almost two times faster).

Threading gives the similar results as forking, but only for JRuby and Rubinius. Running the sample with threads on MRI consumes a bit more time than the sequential method. There are at least two reasons. Firstly, GIL forces sequential threads execution, therefore in a perfect world the execution time should be the same as for the sequential run, but there also occurs a loss of time for GIL operations (switching between threads etc.). Secondly, there is also needed some overhead time for creating threads.

This example doesn’t give us an answer to the question about the sense of usage threads in MRI. Let’s see another one.

Snooze Test

Runs a sleep method.

class SnoozeTest < Test
  def perform
    sleep 1
  end
end

Here are the results

MRIJRubyRubinius
sequential4.0046204.0060004.003186
forking1.022066–1.028381
threading1.0015481.0040001.003642

As you can see, each implementation gives similar results not only in the sequential and forking runs, but also in the threading ones. So, why MRI has the same performance gain as JRuby and Rubinius? The answer is in the implementation of sleep.

MRI’s sleep method is implemented with rb_thread_wait_for C function, which uses another one called native_sleep. Let’s have a quick look at it’s implementation (the code was simplified, the original implementation could be found here):

static void
native_sleep(rb_thread_t *th, struct timeval *timeout_tv)
{
  ...

  GVL_UNLOCK_BEGIN();
  {
    // do some stuff here
  }
  GVL_UNLOCK_END();

  thread_debug("native_sleep donen");
 }

The reason why this function is important is that apart from using strict Ruby context, it also switches to the system one in order to perform some operations there. In situations like this, Ruby process has nothing to do… Great example of time wasting? Not really, because there is a GIL saying: “Nothing to do in this thread? Let’s switch to another one and come back here after a while”. This could be done by unlocking and locking GIL with GVL_UNLOCK_BEGIN() and GVL_UNLOCK_END() functions.

The situation becomes clear, but sleep method is rarely useful. We need more real-life example.

File Downloading Test

Runs a process which downloads and saves a file.

require "net/http"

class DownloadFileTest < Test
  def perform
    Net::HTTP.get("upload.wikimedia.org", "/wikipedia/commons/thumb/7/73/Ruby_logo.svg/2000px-Ruby_logo.svg.png")
  end
end

There is no need to comment the following results. They are pretty similar to those from the example above.

1.003642JRubyRubinius
sequential0.3279800.3340000.329353
forking0.104766–0.121054
threading0.0857890.0940000.088490

Another good example could be the file copying process or any other I/O operation.

Conclusions

  • Rubinius fully supports both forking and threading (since version 2.X, when GIL was removed). Your code could be concurrent and run in parallel.
  • JRuby does a good job with threads, but doesn’t support forking at all. Parallelism and concurrency could be achieved with threads.
  • MRI supports forking, but threading is limited by the presence of GIL. Concurrency could be achieved with threads, but only when running code goes outside of the Ruby interpreter context (e.g IO operations, kernel functions). There is no way to achieve parallelism.

Related articles

Software Development

Build Future-Proof Web Apps: Insights from The Codest’s Expert Team

Discover how The Codest excels in creating scalable, interactive web applications with cutting-edge technologies, delivering seamless user experiences across all platforms. Learn how our expertise drives digital transformation and business...

THECODEST
Software Development

Top 10 Latvia-Based Software Development Companies

Learn about Latvia's top software development companies and their innovative solutions in our latest article. Discover how these tech leaders can help elevate your business.

thecodest
Enterprise & Scaleups Solutions

Java Software Development Essentials: A Guide to Outsourcing Successfully

Explore this essential guide on successfully outsourcing Java software development to enhance efficiency, access expertise, and drive project success with The Codest.

thecodest
Software Development

The Ultimate Guide to Outsourcing in Poland

The surge in outsourcing in Poland is driven by economic, educational, and technological advancements, fostering IT growth and a business-friendly climate.

TheCodest
Enterprise & Scaleups Solutions

The Complete Guide to IT Audit Tools and Techniques

IT audits ensure secure, efficient, and compliant systems. Learn more about their importance by reading the full article.

The Codest
Jakub Jakubowicz CTO & Co-Founder

Subscribe to our knowledge base and stay up to date on the expertise from the IT sector.

    About us

    The Codest – International software development company with tech hubs in Poland.

    United Kingdom - Headquarters

    • Office 303B, 182-184 High Street North E6 2JA
      London, England

    Poland - Local Tech Hubs

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Warsaw, Poland

      The Codest

    • Home
    • About us
    • Services
    • Case Studies
    • Know How
    • Careers
    • Dictionary

      Services

    • It Advisory
    • Software Development
    • Backend Development
    • Frontend Development
    • Staff Augmentation
    • Backend Developers
    • Cloud Engineers
    • Data Engineers
    • Other
    • QA Engineers

      Resources

    • Facts and Myths about Cooperating with External Software Development Partner
    • From the USA to Europe: Why do American startups decide to relocate to Europe
    • Tech Offshore Development Hubs Comparison: Tech Offshore Europe (Poland), ASEAN (Philippines), Eurasia (Turkey)
    • What are the top CTOs and CIOs Challenges?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Copyright © 2025 by The Codest. All rights reserved.

    en_USEnglish
    de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek en_USEnglish