Project

General

Profile

Actions

Bug #163

closed

Thread.priority= is effectively a no-op

Added by pragdave (Dave Thomas) over 14 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
Backport:
[ruby-dev:35117]

Description

=begin
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?
=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0