From: Dave Thomas <redmine@...>
Date: 2008-06-16T12:05:43+09:00
Subject: [ruby-dev:35117] [Ruby 1.9 - Bug #163] (Open) Thread.priority= is effectively a no-op

チケット #163 が報告されました。 (by Dave Thomas)

----------------------------------------
Bug #163: Thread.priority= is effectively a no-op
http://redmine.ruby-lang.org/issues/show/163

起票者: Dave Thomas
ステータス: Open
優先度: Normal
担当者: 
カテゴリ: 
Target version: 


I raised the following back in January:

Is it reasonable to expect the following to produce differing counts in the result array?

 counts = [ 0 ] * 10 
 Thread.abort_on_exception = true
 10.times do |i|
  thread = Thread.new(i) do |index|
    Thread.current.priority = index
    loop do
      counts[index] += 1
      Thread.pass
    end
  end 
 end
 sleep 1
 p counts

I get  [6176, 6173, 6167, 6173, 6174, 6175, 6177, 6178, 6174, 6177]

Matz replied:

I don't know the rationale behind, but at least on Linux:

 * the default scheduling policy is SCHED_OTHER.  Ruby does not   explicitly specify scheduling policy.
 * for SCHED_OTHER, min and max of priority is both zero
 * the specified priority is rounded to zero
 * as a result, no priority change happens

We have to ask Koichi if it's a bug or not.

Given this: (a) is it a Ruby bug, and (b) if not, should we remove the method, as it might confuse folks?


----------------------------------------
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://redmine.ruby-lang.org/my/account