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…

1 Like

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)

1 Like

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.


Okay, kind of a dead thread, but…

I loaded the trial version of 2019, and the above code works. Timing:

0.743 using threads, 6.100 unthreaded

So, not calling anything in the SU API, threads do work on windows.

I did notice that the code had a glob pattern (ary = Dir["C:/Greg/GitHub/ruby/*.c"]) in thread_pool_test.rb that needs to be changed to run on one’s system. Just needs to be a pattern with a bunch of files…