Take the 2-minute tour ×

Ruby 1.9 is supposed to have native threads, and GIL is supposed to lift if some threads enters native code (like GUI toolkit main loop or C implementation of some Ruby lib).

But if i start following simple code sample that displays GUI in main thread and do some basic math in separate thread - the GUI will hang out badly, try to resize window to see it yourself. I have checked with different GUI toolkit, Qt (qtbindings gem) - it behaves exactly same. Tested with Ruby 1.9.3-p0 on Windows 7 and OSX 10.7

require 'tk'
require 'thread'
Thread.new { loop { a = 1 } }

Same code in Python works fine without any GUI hangs:

from Tkinter import *
from threading import *
class WorkThread( Thread ) :
  def run( self ) :
    while True :
      a = 1

What i'm doing wrong?


It seems where is no such problem on Ubuntu linux, so my question is mainly about Windows and OSX.


Some people points out that where is no such problem on OSX. So i assembled out a step-by-step guide to isolate and reproduce a problem:

  1. Install OSX 10.7 Lion via "Recovery" function. I used our test department MB139RS/A mac mini for test.
  2. Install all updates. The system will look like this: enter image description here
  3. Install latest ActiveTcl from activestate.com, in my case it's ActiveTcl 8.5.11 for OSX.
  4. Download and unpack latest Ruby source code. In my case it's Ruby 1.9.3-p125. Compile it and install replacing system Ruby (commands below). You will end up with latest ruby with built-in Tk support: enter image description here
  5. Create a test.rb file with code from my example and run it. Try resizing a window - you will see terrible lags. Remove thread from code, start and try resizing a window - lags are gone. I recorded a video of this test.

Ruby compilation commands:

./configure --with-arch=x86_64,i386 --enable-pthread --enable-shared --with-gcc=clang --prefix=/usr
sudo make install
share|improve this question
Not sure, but has Ruby 1.9 still got a GIL (Global Interpreter Lock)? That'd totally explain your problem... –  Romain Jan 30 '12 at 12:40
@Romain How GIL explains my problem? Python has same GIL and no problem. –  Eye of Hell Jan 30 '12 at 12:52
GIL means only a single thread can run ruby code at once, so if you background calculation can use it, your UI code cannot. –  Romain Jan 30 '12 at 12:58
@Romain Python has same GIL and no such problems. Ruby scheduler will stop background thread after some time (around 100 ruby instructions?) and give some CPU time to another threads. Doing such switches very fast, Ruby will achieve near parallel execution. For example, if you start two ruby threads that will both run ruby code, Ruby will switch between threads very fast, so for you they will be executed just like in parallel. –  Eye of Hell Jan 30 '12 at 13:01
Makes sense. Don't see what's wrong with your code anyhow. And since it cannot be the GIL... –  Romain Jan 30 '12 at 13:12
show 2 more comments

4 Answers

This hang can be caused by C code of Ruby bindings in Toolkit. As you know, ruby threads have a global lock : the GIL. It seems that mixing between Ruby bindings' C thread, Tk C thread and Pure Ruby thread is not going well.

There's a documented workaround for a similar case, you can try to add those lines before require 'tk' :

module TkCore 

Graphical toolkit needs a main thread in order to refresh graphical elements. If your thread is in an intensive computation, your thread is requesting heavily the lock and so it is interfering with toolkit's thread.

You can avoid use of sleep trick if you want. In Ruby 1.9, you can use Fiber, Revactor or EventMachine. According to oldmoe, Fibers seems to be quite fast.

You can also keep Ruby threads if you can use IO.pipe. That's how parallel tests were implemented in ruby 1.9.3. It seems to be a good way to workaround Ruby threads and GIL limitations.

Documentation shows a sample usage :

rd, wr = IO.pipe

if fork 
  puts "Parent got: <#{rd.read}>"
  puts "Sending message to parent"
  wr.write "Hi Dad"

The fork call initiates two processes. Inside if, you are in the parent process. Inside else, you are in the child. The call to Process.wait closes child process. You can, for instance, try to read from your child in your main gui loop, and only close & wait for the child when you have received all the data.

EDIT: You'll need win32-process if you choose to use fork() under Windows.

share|improve this answer
Unfortunately, adding this line before require 'tk' changes absolutely nothing on both Windows and OSX. GUI still hangs badly. Have you checked this solution yourself? Maybe you can paste entire code here, maybe i miss something? –  Eye of Hell Feb 3 '12 at 9:41
Nope, I haven't tried myself this workaround. Did you try with jruby ? –  Coren Feb 3 '12 at 9:52
And maybe the problem is with loop call. Did you try with a while true, like you did with Python ? –  Coren Feb 3 '12 at 9:55
@EyeofHell not a solution, but a workaround: REXML is notoriously slow. If you were to switch to Nokogiri for XML processing, your lags would go away... –  Mark Thomas Feb 7 '12 at 12:46
@EyeofHell C bindings with Tk are quite hard to read. It's not clear to me what kind of threads they use. Anyway, it means that IO.pipe should solve your refresh problem –  Coren Feb 7 '12 at 15:23
show 11 more comments

If you're serious about using multiple threads, you might want to consider using JRuby. It implements Ruby Threads using Java threads, giving you access to the Java concurrency libraries, tools, and well tested code.

For the most part, you just replace the ruby command with the jruby command.

Here's one place to start. https://github.com/jruby/jruby/wiki/Concurrency-in-jruby

share|improve this answer
I know what is JRuby. I'm just curios what is happening - i can't understand the MRI behavior i observe O_O. It can't be like this if GIL is release. It can't be like this if GIL is not released. –  Eye of Hell Feb 14 '12 at 17:22
add comment

Depending on platform you might set priority of threads:

require 'tk'
require 'thread'
require 'rexml/document'
t1 = Thread.new { loop { a = 1 } }
t1.priority = 0
t2 = TkRoot.new.mainloop()
t2.priority = 100
share|improve this answer
No effect on Windows :(. Seems this behavior is not related to thread priority / CPU usage. –  Eye of Hell Feb 7 '12 at 14:12
add comment

Your thread block will use 100% cpu, this is really unlikely any real code will eat that much (if you are doing really intensive calculations you should consider another language), maybe try adding some pauses:

require 'tk'
require 'thread'
require 'rexml/document'
Thread.new { loop { sleep 0.1; a = 1 } }

Your code works fine for me on Mac OS X 10.7 with 1.9.3 btw.

That said as much as I love ruby but the current gui libraries state is really bad in my opinion and I avoid using it for that.

share|improve this answer
In python code it's also 100% CPU load but no GUI freezes. Multithreading is all about executing multiple threads, regardless of CPU usage per thread. For example, if you start TWO ruby threads with same infinity loop, both will work perfectly in parallel, using 50% CPU each. So whu GUI is not working this way? –  Eye of Hell Jan 31 '12 at 10:19
About OSX 10.7 - just use resize instead of window move, OSX will move window without lags even if GUI is not responding, it's OS feature. –  Eye of Hell Jan 31 '12 at 10:20
ok with resizing I got lag too :) –  Schmurfy Jan 31 '12 at 15:55
I think what is happening is that the gui mainloop is in C, since your ruby code is taking a lot of cpu the application spend more time on the ruby side than on the C side. I never used tk but this hypotesis should be close to the truth. (I have no idea how it works on python and why it works differently with ruby maybe the library architecture is just different) –  Schmurfy Jan 31 '12 at 15:59
AFAIK Ruby and Python uses same tcl/tk library. Anyway, situation is same with any toolkits i know: Tk, Qt, GTK etc. All works fine in python, terrible GUI lag in Ruby. My question is "why it is so" :). –  Eye of Hell Jan 31 '12 at 16:04
show 1 more comment

Your Answer


