[Ruby 1.9 - Bug #163] (Open) Thread.priority= is effectively a no-op

e$B%A%1%C%He(B #163 e$B$,Js9p$5$l$^$7$?!#e(B (by Dave T.)

Bug #163: Thread.priority= is effectively a no-op

e$B5/I<<Te(B: Dave T.
e$B%9%F!<%?%9e(B: Open
e$BM%@hEYe(B: 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
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?

e$B%A%1%C%He(B #163 e$B$,99?7$5$l$^$7$?!#e(B (by Yusuke E.)

e$BC4Ev<Te(B Yusuke E.e$B$+$ie(BKoichi Sasadae$B$KJQ99e(B

I have three choice:

(1) make Thread#priority= deprecated (or remove)
(2) add “Not available on all platforms.” to its document
(3) very ad-hoc fix [ruby-dev:33124]
(4) another way that I cannot think of

Please select :slight_smile:


e$B%A%1%C%He(B #163 e$B$,99?7$5$l$^$7$?!#e(B (by Yusuke E.)

e$B%9%F!<%?%9e(B Opene$B$+$ie(BClosede$B$KJQ99e(B

Applied in changeset r18570.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs