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

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

Reply via email to