Thomas, you are right. Until now I have been using it for non-heavy calculations, but I just tested with a heavy calculation that occupies Ruby 100% of the time. Running inside a thread alongside my UI timer loop, it didn't freeze Sketchup at all, but made it noticeably laggy. To fix this, I added some time to the UI.start_timer, so that Sketchup does have time to run Ruby-free.

eps = 100 #Executions per second
rr = 0.25 #Fraction of time devoted to Ruby
UI.start_timer((1.0-rr)/eps, true) {sleep rr/eps}

I know, this will probably break anything in your thread requiring short and accurate timing. The execution will be 'jumpy' if you are really looking at things in the millisecond range. However, the sleep function still sleeps the expected amount of time.

The one thing I have found is that Sketchup crashes if I try to drag the Ruby window. Not sure why, but it isn't a worry for what I am using it for.

I just dug through the topics on here trying to figure out how to do exactly this, making threads run without blocking Sketchup. I ended up figuring out my own solution, and I hope it's helpful to someone. It's a hack, but it seems to do what I need without any performance problems. I am using it to keep sockets alive, which are running in (green) threads.

eps = 100 #Executions per second
UI.start_timer(0.0, true) {sleep 1.0/eps}

I will try to explain my theory as to why it works. As discussed the other topics on threading, Sketchup normally freezes Ruby execution when no blocking Ruby functions are running, meaning that my threads will only run if I am also running a Ruby function in the console. Apparently, though, it isn't a problem the other way around, meaning once Sketchup starts executing its functions, making Ruby run can't stop it. Sleeping for a hundredth for a second gives your thread time to execute, but one hundredth of a second is over well in time for the Sketchup UI to reach its next natural tick. And by that time, it isn't being blocked by Ruby, and as such, can continue, execute normal Sketchup code, and then go back to the Ruby sleep.

It even works nicely alongside SketchyPhysics (when running a simulation) without BugSplat or performance problems.