From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 12:49:36 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 0700537B401; Mon, 7 Jul 2003 12:49:36 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 519AD43FBF; Mon, 7 Jul 2003 12:49:35 -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 h67JnYAI016268; Mon, 7 Jul 2003 15:49:34 -0400 (EDT) Date: Mon, 7 Jul 2003 15:49:34 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2003 19:49:36 -0000 On Mon, 7 Jul 2003, John Baldwin wrote: > > On 07-Jul-2003 Daniel Eischen wrote: > > On Mon, 7 Jul 2003, John Baldwin wrote: > > > >> Just wondering why the PTHREAD_{MIN,MAX}_PRIORITY macros referenced in > >> the pthread_{get,set}schedparam() man pages are not available to > >> applications but are hidden in pthread_private.h. It would seem that > >> these values should be exported in pthread.h. > > > > Because they are not defined by the POSIX spec. According > > to POSIX you should use: > > > > sched_get_priority_max(), sched_get_priority_min() > > > > but it is confusing because these are specified for the process > > scheduling. The values returned by these system calls, do not > > necessarily correspond to the values used by our thread libraries > > (in fact, they don't). > > They do if you use SCHED_RR (which is the default policy) or SCHED_FIFO. > SCHED_OTHER uses -20 to 20 (nice values). And SCHED_OTHER is where the confusion lies. In our thread libraries (except libthr), SCHED_OTHER is treated the same as SCHED_RR (priorites 0 .. 31). This no matchy kernel. If you try to use those values in pthread_attr_setschedparam() or pthread_setschedparam(), you would get EINVAL for values less than 0. > > I believe somewhere in the old spec, there were supposed to be > > at least 31 or 32 priorities (I can't seem to find that mentioned > > in the new spec). Our thread libraries, at least libc_r and > > libpthread, use priorities 0 .. 31. > > > > I don't really know how to handle this. We can wrap > > sched_get_priority_{min,max}(), but how do we know whether > > the application wants process priorities or thread > > priorities? > > Ugh. Perhaps the manpage should at least be updated to not > reference the macros. What does POSIX say about the confusion > between sched_get_priority_{min,max}? Sure, update the man pages if you want ;-) I have not found anything yet regarding sched_get_priority_{min,max} confusion in the POSIX spec... -- Dan Eischen