From: Daniel Merk Date: 2008-08-22T20:41:22+09:00 Subject: Re: Newly created thread blocks all others in Ruby 1.8.7 patchlevel 72 on Cygwin Hi Pit, thanks again for the response. I backgraded to Ruby 1.8.6 to make some tests too, the behavior is as you have described it. Here the test code I have used: Thread.main.priority = 0 count1 = count2 = 0 a = Thread.new do puts "starting thread a" Thread.current.priority = -1 loop { count1 += 1 } end b = Thread.new do puts "starting thread b" Thread.current.priority = -1 loop { count2 += 1} end puts "stalling main thread for 1 second" sleep 1 a.kill; b.kill puts "count1: #{count1}" puts "count2: #{count2}" On Ruby 1.8.6 I get the following output: starting thread a starting thread b stalling main thread for 1 second count1: 953760 count2: 953753 So this is fine and what I expected (if I lower thread b priority to -2, count2 drop to absolute 0. This is quite awful, but ok, I'll stop complaining ;-). On Ruby 1.8.7 however, I just see: starting thread a starting thread b stalling main thread for 1 second No more output from here on. It seems that the sleep statement does not return. Thanks however for your help. Regards Daniel On 8/21/08, Pit Capitain wrote: > Hi Daniel. > >> The behaviour I expect from threads in general is that they virtually run >> in >> parallel. So I expect each active thread to be at least scheduled, but not >> blocked, even if it has a low priority. > > From looking at the source code of 1.8.6 and from running some tests > this doesn't seem to be the case. Threads with lower priority are > blocked as long as there are runnable threads with higher priority. > >> If there is a total of two threads >> that have the same priority, I expect the thread scheduler to assign 50% >> of >> processing resources to each of them. In earlier Ruby versions (e.g. >> 1.8.6), >> this is exactly what has happened. > > Indeed this seems to be the case in 1.8.6, again from looking at the > source and running some tests. If this doesn't work in Ruby 1.8.7, you > should perhaps report it on ruby-core. > >> I could reach that behavior in the example before (which is as I stated an >> "official" one, since you can also find it in the only ruby core >> documentation of the thread class: >> http://www.ruby-doc.org/core/classes/Thread.html#M000480) by inserting >> sleep >> statements into the loop-blocks. > > AFAIK there's no official description of Ruby yet. There are projects > trying to fill this gap with executable specifications. > >> I could then control the amount of >> processing time for each thread by balancing the sleep times, therefore >> emulating priority. But then I would mimic the behavior that usually rubys >> thread scheduler should perform for me. > > I don't buy this "should". The documentation you've cited clearly > says, that higher-priority threads will run before lower-priority > threads. > > Regards, > Pit > >