Ruby 2.0.0 Threads in SU | how to keep a subthread running?
-
Hmm, I tried your technique, but I still get like a descent time.
Aha! When I enter this in console and unfocus the window the thread stops running, but when I refocus, it starts running again. I think that's how Windows work...
-
Hmm.
-
I was wrong about automatic Windows Thread Suspension. All you need to due is call thread.run or thread.wakeup after creating the thread:
seconds = 0; t = Thread.new(){ while true; seconds += 1; sleep(1) end }; t.runIt seems to work even if I suspend/deactivate the window. Can you verify?
-
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 -
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.
-
Btw, when sharing variables between threads you probably want to use Mutex. Not that it solves this issue though.
-
Ok tt_su, I might have to go the hard way then, and use native threads in a c++ extension.
-
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
-
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.
-
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. -
What about Ruby 2.1 ?
-
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. -
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) enddoes help a bit, but ofcourse, this drastically affects SU performance. Even sleeping for 0.01 seconds does..
-
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.
-
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...
-
Yea, that's another limitation. You can do calculations and such in other threads. But Ruby calls must be done some the main thread.
-
@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.
Advertisement