From owner-freebsd-threads@FreeBSD.ORG Sat May 1 07:27:30 2004 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 62B1116A4CF for ; Sat, 1 May 2004 07:27:30 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56B4243D1F for ; Sat, 1 May 2004 07:27:29 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h91.vuokselantie10.fi [193.64.42.145]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i41ERRmo020212; Sat, 1 May 2004 17:27:27 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <4093B3CC.90502@he.iki.fi> Date: Sat, 01 May 2004 17:27:24 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: system priorities 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: Sat, 01 May 2004 14:27:30 -0000 Daniel Eischen wrote: > >It looks like rtprio will set the priority of the first >KSEG in the proc's list of KSEGs. This isn't necessarily >the first KSEG created (main). In fact, newly created >KSEGs get inserted onto the head of the list, so rtprio() >may act on different KSEGs depending on if it is called >before or after any KSEG creations. > > > This sounds like a bug. Could it change the KSEG which called the rtprio so there would be some deterministic behaviour to the rtprio if used in threaded program? So I take it from this that rtprio is also broken for libthr? >I would really like a Solaris-like priocntl() so that you >can specify which KSEG (or whatever thing that will hold >the priority in the future) to act on. > > > I fail to understand the value of being able to point to other threads for priority setting? Or are you talking about a facility which would exist below the rtprio call? Pete