From owner-freebsd-threads@FreeBSD.ORG Sat May 1 07:52:20 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 A231716A4CE for ; Sat, 1 May 2004 07:52:20 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1773A43D2F for ; Sat, 1 May 2004 07:52:20 -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.10/8.12.1) with ESMTP id i41EqJS8027345; Sat, 1 May 2004 10:52:19 -0400 (EDT) Date: Sat, 1 May 2004 10:52:19 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <4093B3CC.90502@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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:52:20 -0000 On Sat, 1 May 2004, Petri Helenius wrote: > 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? Yes. > >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? The Solaris priocntl() lets you set/get: P_LWPID The id argument is an LWP ID. The priocntl function applies to the LWP with the specified ID within the calling process. P_PID The id argument is a process ID specifying a single process. The priocntl() function applies to all LWPs currently associated with the specified process. P_PPID The id argument is a parent process ID. The priocntl() function applies to all LWPs currently associated with processes with the specified parent process ID. P_PGID The id argument is a process group ID. The priocntl() function applies to all LWPs currently associated with processes in the specified process group. P_SID The id argument is a session ID. The priocntl() func- tion applies to all LWPs currently associated with processes in the specified session. P_TASKID The id argument is a task ID. The priocntl() function applies to all LWPs currently associated with processes in the specified task. P_CID The id argument is a class ID (returned by the priocntl() PC_GETCID command as explained below). The priocntl() function applies to all LWPs in the speci- fied class. P_UID The id argument is a user ID. The priocntl() function applies to all LWPs with this effective user ID. P_GID The id argument is a group ID. The priocntl() function applies to all LWPs with this effective group ID. P_PROJID The id argument is a project ID. The priocntl() func- tion applies to all LWPs with this project ID. P_ALL The priocntl() function applies to all existing LWPs. The value of id is ignored. The permission restric- tions described below still apply. P_MYID The calling LWP's LWP_ID, PPID, GID, SID, TASKID, CID, UID, GID, or PROJID... We probably don't need all these, but perhaps some of them could be useful. -- Dan Eischen