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.
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
counts[index] += 1
I get [6176, 6173, 6167, 6173, 6174, 6175, 6177, 6178, 6174, 6177]
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?