Date: Sat, 14 Oct 2000 09:34:15 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: jdp@polstra.com Cc: current@freebsd.org Subject: Re: Recent thread changes Message-ID: <Pine.SUN.3.91.1001014091525.13283A-100000@pcnet1.pcnet.com> In-Reply-To: <200010141008.e9EA8sG44179@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 14 Oct 2000 jdp@polstra.com wrote:
> In article <200010132232.SAA05650@pcnet1.pcnet.com>,
> Daniel Eischen <eischen@vigrid.com> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1001014091525.13283A-100000>