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

SR20VET

I have the same issues with your latest code. When I simply enter the code, press ENTER, wait a couble of seconds and then type seconds, still not a proper amount of seconds.

Although it seems that, while I'm writing this post, the thread is running... while at the start of the thread I entered "seconds" a couple of times, still with about 10 seconds.

I'll try: seconds = 0; t = Thread.new(){ while true; seconds += 1; sleep(1) end }; t.run
and puts "seconds: #{seconds} and time: #{Time.now}"; a few times. Here is the result in the console, it does run, but not perfect:

seconds = 0; t = Thread.new(){ while true; seconds += 1; sleep(1) end }; t.run
#<Thread:0x92a18d8 run>
puts "seconds: #{seconds} and time: #{Time.now}";
seconds: 1 and time: 2014-08-14 23:39:00 +0200
nil
puts "seconds: #{seconds} and time: #{Time.now}";
seconds: 7 and time: 2014-08-14 23:39:07 +0200
nil
puts "seconds: #{seconds} and time: #{Time.now}";
seconds: 14 and time: 2014-08-14 23:39:15 +0200
nil
puts "seconds: #{seconds} and time: #{Time.now}";
seconds: 25 and time: 2014-08-14 23:39:28 +0200
nil
puts "seconds: #{seconds} and time: #{Time.now}";
seconds: 34 and time: 2014-08-14 23:39:39 +0200
nil
puts "seconds: #{seconds} and time: #{Time.now}";
seconds: 43 and time: 2014-08-14 23:39:50 +0200
nil

tt_su

Yes, we have observed this. We're not sure why as Ruby claims native threads in 2.0 as oppose to the "green" threads in 1.8 - but yet something is amiss. Might be related to the Ruby interpreter running as embedded in SketchUp - which Ruby isn't really designed to. If you run standalone you will probably find it works fine.

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.