Date: Tue, 8 Jul 2003 20:12:16 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@FreeBSD.org> Cc: threads@FreeBSD.org Subject: Re: libc_r silliness Message-ID: <Pine.GSO.4.10.10307082002420.10003-100000@pcnet5.pcnet.com> In-Reply-To: <XFMail.20030708200124.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10307082002420.10003-100000>