Issue #3176 has been updated by caleb clausen.

File thread-priorities-final.tgz added

I've divided my patch into 13 pieces for easier consumption. Since I can only upload 1 file at a time, I tarred them together. I hope this will be the final version of this patch, but I'm always willing to revise if there is more feedback. Koichi, I am most of all hoping to hear from you, since it has been said that you had some kind of objection to this patch. 

I did try to create a more comprehensive benchmark, but I ended up crashing the interpreter, so I'm kind of stuck on that front at the moment. (See bug #3312.)

Kosaki, I have tried using setpriority on linux to get the OS to handle priorities, but it failed in the same way that pthread_setschedparam did; the test script would never finish and wouldn't even respond to ^C. I have no idea why this is failing so badly. (Maybe a bug in linux?? More likely a bug in my understanding.) In any case, another problem with this approach is that you won't readily be able to set a thread to higher priority than the main thread. Altho there may be ways around this, they come with their own issues. For instance, if a ruby process is started at the lowest possible priority (highest nice level) it won't be  possible to have threads within that process be a different priority at all. On reflection, it seems better for ruby to manage its own thread priority queue (at least on linux) and have a guaranteed level of support for priorities and fixed number of available priorities. Your other patch (for native_thread_yield) looks pretty good, but I haven't!
  tried it.
 
I've tested this on linux, but not anything else. I don't really have access to any other systems to test with. Please, can someone help me test this patch on other OS's?
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3176

----------------------------------------
http://redmine.ruby-lang.org