On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > The range of valid priorities has also changed, perhaps
> > requiring a library version bump. The range of valid priorities
> > is not visible outside of the threads library. The only
> > way it can be determined is through trial and error, so
> > it _shouldn't_ be an issue.
>
> I thought you could get that information with sched_get_priority_min()
> and sched_get_priority_max(). Is that not the case?
Not really. Those return the kernels POSIX priority range for
processes. I am unsure as to how to deal with those in the
threads library; do we want to wrap those system calls and
return thread priority ranges?
The kernels range for SCHED_OTHER is -20 .. 20, and 0 .. 31
for SCHED_FIFO and SCHED_RR. The threads library priority
range changed from 0 .. 126 to 0 .. 31 (for all scheduling
classes). Anyone using sched_get_priority_{min|max} for
_thread_ priority ranges would have problems if the scheduling
class was SCHED_OTHER, but wouldn't see any difference
for SCHED_FIFO or SCHED_RR.
Still, I know this change breaks at least one port; lang/gnat
uses the full range of priorities, only because it was my
port and I knew the priority range of the threads library.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
