From owner-freebsd-threads@FreeBSD.ORG  Tue Jul  8 18:06:23 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 17C0A37B43C; Tue,  8 Jul 2003 18:06:23 -0700 (PDT)
Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 59D9F43F3F; Tue,  8 Jul 2003 18:06:22 -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 h6916JAI020360;
	Tue, 8 Jul 2003 21:06:20 -0400 (EDT)
Date: Tue, 8 Jul 2003 21:06:19 -0400 (EDT)
From: Daniel Eischen <eischen@vigrid.com>
X-Sender: eischen@pcnet5.pcnet.com
To: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <XFMail.20030708202828.jhb@FreeBSD.org>
Message-ID: <Pine.GSO.4.10.10307082043470.16930-100000@pcnet5.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: threads@FreeBSD.org
cc: David Xu <davidxu@viatech.com.cn>
Subject: Re: libc_r silliness
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
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 01:06:23 -0000

On Tue, 8 Jul 2003, John Baldwin wrote:
> 
> On 09-Jul-2003 Daniel Eischen wrote:
     ^^ Is there a time lag somewhere :-)

> > On Tue, 8 Jul 2003, John Baldwin wrote:
> >> 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.
> 
> You aren't supposed to hard code 10, you're supposed to derive
> your value from the min() and max() functions as far as I can
> tell. :-P

Well, yup, that's what you're _suppose_ to do...  I guess
we can do this.  To summarize:

  sched_get_schedparam(), sched_set_schedparam(),
  sched_get_priority_min(),  sched_get_priority_max()
  will be provided by the thread libraries (unless
  kernel and thread priorities match for all scheduling
  protocols).

  The library functions sched_get_schedparam(),
  sched_get_priority_min(), and sched_get_priority_max()
  will call the respective system calls and convert kernel
  SCHED_OTHER priorities to thread SCHED_OTHER priorities
  before returning.

  The library function sched_set_schedparam() will
  convert thread SCHED_OTHER priorities to kernel
  SCHED_OTHER priorities before making the actual
  system call.

If the thread priority ranges for SCHED_FIFO and SCHED_RR
do not match the kernel priority ranges, the thread libraries
will do similar conversions (they might just as well do
the conversions even if they are the same).

-- 
Dan Eischen