From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 17:28:20 2003 Return-Path: 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 9DDE237B401 for ; Tue, 8 Jul 2003 17:28:20 -0700 (PDT) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED3AF43F3F for ; Tue, 8 Jul 2003 17:28:19 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1513 invoked from network); 9 Jul 2003 00:28:19 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 9 Jul 2003 00:28:19 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h690SEGI097286; Tue, 8 Jul 2003 20:28:15 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 08 Jul 2003 20:28:28 -0400 (EDT) From: John Baldwin To: Daniel Eischen cc: threads@FreeBSD.org cc: David Xu Subject: Re: libc_r silliness X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2003 00:28:20 -0000 On 09-Jul-2003 Daniel Eischen wrote: > 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. We could use 0..39 for process priorities and have the kernel do the right math to convert that to a nice value. The kernel process priorities don't _have_ to be nice values. >> 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 -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/