Need help on writing threaded plugin code

RichMorin

I've looked around for information on writing threaded plugin code,
but I'm not having much luck. (Of course, part of the problem has to do with the overloading of the words "thread" and threaded". <g>) Does anyone here know the ropes?

I have a plugin that needs to scan a directory for the presence of new files, processing and removing them when they appear. Something like this:


loop do             # Loop forever, handling files.
  paths = Dir.glob(patt)

  if paths.empty?   # Nothing to do; zzz...
    sleep(0.05)
  else              # Process incoming messages.
    paths.each do |path|
      process_input(path)
      break if @terminate_bd
    end
  end
  break if @terminate_bd
end

If I run this code in my plugin, it works just fine. Unfortunately, it also makes SketchUp unresponsive to other input, keeps the Ruby Console from updating, etc. So, I tried giving the code its own Thread:


Thread.new do
  loop do             # Loop forever, handling files.
    ...
  end
end

This doesn't tie up SketchUp, but it doesn't work, either. In fact, it appears that the code in the thread never gets run at all. Comments? Clues? Suggestions?

-r

thomthom

All the previous threads ... (no pun intended) on SketchUp Ruby threads I've seen has said that it doesn't work. Pain and suffering is the general jest of it AFIK. (I've not tried it myself.)

You should get some threads if you search the archive.

AdamB

Specifically, Ruby Threads are "Green threads". Think of it as an "emulated" thread that Ruby creates internally by having its own mini-scheduler like an OS has but here sharing out itself. So Ruby threads can never be multicore for example.

Also you need to be clear why you want to thread your task. If your task doesn't actually have external blocking situations (waiting for something to be ready), you will never gain any performance by threading. In fact you more likely will reduce performance.

Lastly, if you use "real" threads, you need to ensure that the APIs you use from those threads is "thread safe" - meaning it can deal with multiple threads calling into it. AFAIK SketchUp API is not thread safe.

Adam

RichMorin

I have two reasons for thinking that I might need to use threads (or some other solution). Even in the context of show_modal(), it's annoying to have the Ruby Console (etc.) stalled. In the context of show(), it's unacceptable to have the rest of SketchUp stalled.

I'm not married to the idea of threads, but I need some way to detect and process incoming data files. Suggestions?

fredo6

@richmorin said:

I have two reasons for thinking that I might need to use threads (or some other solution). Even in the context of show_modal(), it's annoying to have the Ruby Console (etc.) stalled. In the context of show(), it's unacceptable to have the rest of SketchUp stalled.

I'm not married to the idea of threads, but I need some way to detect and process incoming data files. Suggestions?

Did you try with a timer in JavaScript. It seems that the Browser control window runs in its own thread?

Fredo

thomthom

@unknownuser said:

It seems that the Browser control window runs in its own thread?

hmmm.... not too sure about that. If you open a WebDialog and do some heavy processing even the webdialogs stall.

RichMorin

FWIW, I found a different solution to the problem. Instead of looping, I set up a timer which fires every 0.05 seconds. The associated block looks for files, etc. Seems to work just dandy...

AdamB

@richmorin said:

Even in the context of show_modal(), it's annoying to have the Ruby Console (etc.) stalled. In the context of show(), it's unacceptable to have the rest of SketchUp stalled.

Non-modal dialogs don't block SketchUp. Yer doing it wrong.

thomthom

@richmorin said:

Instead of looping, I set up a timer which fires every 0.05 seconds. The associated block looks for files, etc. Seems to work just dandy...

UI.timer ? or a Javascript timer?
Remember that UI.timer is bugged in pre-SU8. In those versions floating numbers are rounded down - so 0.05 would becomes 0.0.

RichMorin

@thomthom said:

UI.timer ? or a Javascript timer?

This has to be a UI.timer, because it runs in the plugin (telling the plugin when to look for proxied messages from the JavaScript client code).

I'm using SU 8, so the bug you mention isn't a problem for me. However, it would be nice to have a solution that works for earlier versions.