[Lio]

Could you go into more detail about what you see as issues with IO bound tasks?

My understanding is that MRI Ruby provides non-block IO operations if you wrap them in a thread and that it is only CPU bound tasks that are blocked by the GVL.

Is there some other issue related to that?

(JRuby provides fully multi-threading for cpu bound tasks without GVL).

[dosethree]

"My understanding is that MRI Ruby provides non-block IO operations if you wrap them in a thread and that it is only CPU bound tasks that are blocked by the GVL."

All IO operations in ruby are subject to the GIL (global interpreter lock).

[Lio]

GVL is an implementation detail rather than a feature of the language (I believe the term Global VM Lock replaced GIL in the standard library, sometime around ruby 2.0ish I think).

JRuby, for example, has no GVL including for CPU based code; everything there can run in parallel.

Even in MRI Ruby though, wrapping IO operations in a thread allows you to release the GVL when the IO operation blocks.

e.g.

  5.times.map do
    Thread.new do
      Net::HTTP.get('example.com', '/index.html')
    end
  end.each(&:join)

Will perform those network requests in parallel rather than sequencially. This is how ActiveRecord can perform asynchronous database calls in parallel on MRI Ruby.

I got that HTTP example from[1], which has a good write up but it's also covered in Working with Ruby Threads by Jesse Storimer[2].

I asked the original question because in the Concurrent-Ruby Readme they discuss Ruby's mutable references and the possibility of thread safety issues because of that.[3]

1. https://pawelurbanek.com/ruby-concurrent-requests

2. https://www.goodreads.com/book/show/17826435-working-with-ru...

3. https://github.com/ruby-concurrency/concurrent-ruby