libc_r silliness

[John Baldwin]

On 09-Jul-2003 Daniel Eischen wrote:
> On Tue, 8 Jul 2003, John Baldwin wrote:
>> On 08-Jul-2003 Daniel Eischen wrote:
>> > On Tue, 8 Jul 2003, John Baldwin wrote:
>> >> So is X/Open OSI whoever just assuming that the process and thread
>> >> scheduling policies implement identical priority ranges?
>> > 
>> > I dunno, but it seems that is the case.
>> > 
>> > We could add pthread_get_priority_{min,max}_np(int policy) as
>> > non-portable functions.
>> 
>> We could also just force all the thread libraries and kernel to
>> use the same priority ranges.
> 
> I don't want to have SCHED_OTHER with -20 .. 20 in libpthread.

We could use 0..39 for process priorities and have the kernel do
the right math to convert that to a nice value.  The kernel process
priorities don't _have_ to be nice values.
 
>> Another possibility is to have
>> each thread library provide their own sched_get_{min,max} and
>> wrap the sched_{get,set}schedparam() syscalls to massage the
>> thread priority values into their corresponding process priority
>> values to simulate a single priority space for each policy.
> 
> I like this better than the other option, but how do you
> know that when the application calls sched_setschedparam()
> with a priority of 10, that it really came from
> sched_get_priority_min() + 10 (meaning -10) or whether it was
> hardcoded to 10 and really wants 10.

You aren't supposed to hard code 10, you're supposed to derive
your value from the min() and max() functions as far as I can
tell. :-P

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/