[ruby-core:18277] Re: result for mget [last:10 MIME/multipart] (1/1) (ruby-core ML)

Hi,

Giuseppe Bilotta wrote:
>> There are 2 options:
>>
>> 1. This is Ruby's good point, so we must support
>>   OS independent exact thread scheduler
>>   (with development/running cost).
>>
>> 2. We don't need such big mechanism on thread because
>>   other environments don't support it.
>>
>> (optional-3: we should choose 1 or 2 on build/launch timing)
> 
> The ideal solution would be to keep Thread#priority= and map it to the
> appropriate system-level call (SetThreadPriority() on Windows [if Ruby
> uses native threads there], nice() on Linux, etc). However, I have no
> idea how complex this would be to implement.

That is part of 2.

I discuss with matz about it.  Selection "1" should not be accepted. 
  Making another thread scheduler over native thread is "bad" idea. 
  It will become grit in the gears of future release of MRI (and 
other impls).

So as "Ruby's spec", I agree that the behaviour of 
Thread#priority(=) should be "system/implementation dependent".


Let's discuss about MRI 1.9 behaviour:

I implemented another platform-independent way priority management 
scheme which suggested on (Bug #163).

Bug #163:
http://redmine.ruby-lang.org/issues/show/163

Priority scheduler before 1.8 prohibit low-priority thread execution 
if there are high-priority threads (this type scheduler is used on 
real-time system and so on).  Against such scheduler, I implement 
time sharing scheduler with priority, which means that 
"High-priority threads take more time slice".

I limit the range of priority to "-3 ... 3".  default is "0".  If 
you specify over/under that values by Thread#priority=, it will be 
round up/off in that range.

A thread which has positive priority PP, take PN time slices.  A 
thread which has negative priority NP, take 1/NP time slices (skip 
NP times to get time slice).  See thread.c, 
rb_thread_execute_interrupts() for details.


If you want to use "native thread's priority", you can specify as 
built-time option (see thread.c/USE_NATIVE_THREAD_PRIORITY macro). 
Windows' priority scheduler is like 1.8 behaviour (I haven't try it, 
only read MSDN).

-- 
// SASADA Koichi at atdot dot net