Ruby 2.0.0 Threads in SU | how to keep a subthread running?

tt_su

Btw, when sharing variables between threads you probably want to use Mutex. Not that it solves this issue though.

SR20VET

Ok tt_su, I might have to go the hard way then, and use native threads in a c++ extension.

tt_su

As things stand right now that would be the route to go.

We have a GitHub repo with the Ruby libs we use in SketchUp along with Visual Studio and Xcode projects set up: https://github.com/SketchUp/ruby-c-extension-examples

slbaumgartner

According to Programming Ruby 1.9 and 2.0 section 12.2, Ruby 1.9 and 2.0 encountered trouble with numerous existing libraries that were not thread-safe. "So, Ruby compromises: it uses native operating system threads but operates only a single thread at a time." That is very likely what you are seeing.

tt_su

So much for "multi-threading"... sigh
Still, the worker threads appear to act differently under standalone Ruby vs SketchUp embedded Ruby. So we are suffering from some side effect of how Ruby deals with its threads.

Dan Rathbun

What about Ruby 2.1 ?

Anton_S

Here are Ruby 2.1 release notes : https://github.com/ruby/ruby/blob/v2_1_0/NEWS
I haven't found anything with threads though.

SR20VET

To make sure the subthread is running, we have to put the main thread in a sleep state.
This is because Ruby does switch to another thread (if existing) when a thread goes into a sleep state.

Now, is there a way to automatically put the main thread in a sleep state when the user is not interacting with SU? Once the user starts to interact (mouse movement, click, ...) the sleep state should be interrupted.

I'm not aware of such an event in SU.

For now this:

message_pump = UI.start_timer(0.1, true) do
	sleep(0.1)
end

does help a bit, but ofcourse, this drastically affects SU performance. Even sleeping for 0.01 seconds does..

tt_su

I wouldn't go the route of Ruby threads for now. If you really need it then use native threads in C extension.

One scenario where it might be used is where you do multiple calculations in parallel and don't mind locking the main thread. You can then start your worker threads and join them with the main one. But other than that I would not rely on Ruby threads due to the current state of them.

SR20VET

Yep, I've taken the native threads path. Got the thread running, got even an http server running in that thread. But now, GIL is killing me. Can't call ruby from that second native thread...

tt_su

Yea, that's another limitation. You can do calculations and such in other threads. But Ruby calls must be done some the main thread.

icehuli

@sr20vet said:

Yep, I've taken the native threads path. Got the thread running, got even an http server running in that thread. But now, GIL is killing me. Can't call ruby from that second native thread...

May I ask what exactly you are trying to do? I think you can call ruby from that second native thread.
One important point is that the ruby function needs to be involved in the ruby thread, i.e. the SU thread. So in the c-extension there should be two threads, one is the same SU thread, the other is your second native thread. All ruby codes need to run within the SU thread.