Date: Wed, 9 Jul 2003 08:32:20 +0800 From: "David Xu" <davidxu@freebsd.org> To: <deischen@freebsd.org>, "John Baldwin" <jhb@freebsd.org> Cc: threads@freebsd.org Subject: Re: libc_r silliness Message-ID: <005101c345b1$8fdb7cc0$0701a8c0@tiger> References: <Pine.GSO.4.10.10307082002420.10003-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20
From: "Daniel Eischen" <eischen@vigrid.com>
To: "John Baldwin" <jhb@FreeBSD.org>
Cc: "David Xu" <davidxu@viatech.com.cn>; <threads@FreeBSD.org>
Sent: Wednesday, July 09, 2003 8:12 AM
Subject: Re: libc_r silliness
> 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?
> > >=20
> > > I dunno, but it seems that is the case.
> > >=20
> > > We could add pthread_get_priority_{min,max}_np(int policy) as
> > > non-portable functions.
> >=20
> > We could also just force all the thread libraries and kernel to
> > use the same priority ranges.
>=20
> I don't want to have SCHED_OTHER with -20 .. 20 in libpthread.
>=20
> > 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.
>=20
> 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.
>=20
>From a book "Programming for the real world POSIX.4",
The author said about sched_get_priority_max/min:
Notes:
Since the range of scheduling priorities varies from system
to system, applications should refrain from calling the POSIX.4
scheduling algorithms with straight priority numbers. Rather,
a virtual priority range should be used; then it should be =
shifted
appropriately based on the values returned from =
sched_get_priority_min
and sched_get_priority_max.
> --=20
> Dan Eischen
>=20
> _______________________________________________
> freebsd-threads@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to =
"freebsd-threads-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005101c345b1$8fdb7cc0$0701a8c0>