From owner-freebsd-threads@FreeBSD.ORG  Tue Jul  8 17:12:18 2003
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
Delivered-To: freebsd-threads@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2F70737B401; Tue,  8 Jul 2003 17:12:18 -0700 (PDT)
Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 82DBD43F93; Tue,  8 Jul 2003 17:12:17 -0700 (PDT)
	(envelope-from eischen@vigrid.com)
Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4])
	by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h690CGAI011617;
	Tue, 8 Jul 2003 20:12:16 -0400 (EDT)
Date: Tue, 8 Jul 2003 20:12:16 -0400 (EDT)
From: Daniel Eischen <eischen@vigrid.com>
X-Sender: eischen@pcnet5.pcnet.com
To: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <XFMail.20030708200124.jhb@FreeBSD.org>
Message-ID: <Pine.GSO.4.10.10307082002420.10003-100000@pcnet5.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: David Xu <davidxu@viatech.com.cn>
cc: threads@FreeBSD.org
Subject: Re: libc_r silliness
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: deischen@FreeBSD.org
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2003 00:12:18 -0000

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