Are Ruby Threads working on Windows yet?


I was testing and causing an insurmountable memory spikes, I had to Force Quit, so I wrapped it in an Threads array…

      threads = []
      images.each do |img|
        in_file = File.join(dir, img)
        threads << { upscale_double(in_file, args[0],args[1]) }
      threads.each { |thr| thr.join }

the memory still maxed out, but the CPU used all cores and the previously ‘this is never going to complete’ call, resolved itself in a reasonable timeframe…

Although similar has happened on a mac since I started hacking, I was surprised by the multi core activity and then wondered if windows PC’s even dealt with ruby threads yet



No, Ruby threads in SketchUp isn’t behaving properly.


Currently in ruby trunk (what will be Ruby 2.6), both Windows & MacOS are being fully tested and some of the tests are run parallel, which uses pipes & threads to run testing concurrently.

Windows builds have been doing so since 2.5 was in development.

Not necessarily helpful when compatibility with 2.2 and/or 2.0 is needed…


Friday afternoon. Tired of other things. Attached are two files.

thread_pool_q.rb is a generic module that allows one to run a task in threads. It requires a defined collection of objects to perform an operation on, the operation is performed via a passed block. The number of threads defaults to the number of cores available, and can be increased via a multiplier.

If ary is the collection, and meth is the method defining the operation, one can compare threads versus serial via: { |obj| meth(obj) }
  -- and --
ary.each { |obj| meth(obj) }

thread_pool_test.rb is a file that demos ThreadPoolQ.

Note that the ‘binding’ for the block is created outside of the ThreadPoolQ, so any variables available in the method/operation can be used. As to practical uses in SU, I haven’t experimented with threads (in SU) for a long time…

Tested on stand-alone Windows Rubies, 2.0 & trunk.

thread_pool_q.rb (1.1 KB)
thread_pool_test.rb (605 Bytes)


Is this using Ruby’s own threads in any way?


Yes. Both John’s example and thread_pool_q.rb use

thread_pool_q.rb shows one way to limit the number of threads, yet perform a repetitive task using threads.

SU probably won’t like multiple threads each creating DrawingElements at the same time, so using threads in SU is limited…


No, the SketchUp API is not thread-safe. Should never attempt to call the SketchUp API from another thread.
And we still have the issue of Ruby threads not working properly inside of SketchUp. Still don’t know what causes it, but Ruby threads won’t run without the main thread being busy/actively working on something.