From owner-freebsd-arch  Thu Nov 15 12:24:12 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3C58E37B417; Thu, 15 Nov 2001 12:24:06 -0800 (PST)
Received: from dialup-209.245.139.20.dial1.sanjose1.level3.net ([209.245.139.20] helo=mindspring.com)
	by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 164T3M-0005mO-00; Thu, 15 Nov 2001 12:24:05 -0800
Message-ID: <3BF4248D.1735C282@mindspring.com>
Date: Thu, 15 Nov 2001 12:24:45 -0800
From: Terry Lambert <tlambert2@mindspring.com>
Reply-To: tlambert2@mindspring.com
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Watson <rwatson@FreeBSD.ORG>
Cc: Dag-Erling Smorgrav <des@ofug.org>,
	Matthew Dillon <dillon@apollo.backplane.com>,
	Alfred Perlstein <bright@mu.org>, Greg Lehey <grog@FreeBSD.ORG>,
	Bruce Evans <bde@zeta.org.au>, Peter Wemm <peter@wemm.org>,
	freebsd-arch@FreeBSD.ORG
Subject: Re: cur{thread/proc}, or not.
References: <Pine.NEB.3.96L.1011115135118.1877C-100000@fledge.watson.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

Robert Watson wrote:
> The implicit question behind that, though, is: are there places in the
> kernel that will always be locked into using curproc/curthread, simply due
> to the structure and behavior of the kernel environment.  For example, I
> would generally think that 'borrowing' a proc or thread structure is a bad
> idea, rather, you want that proc or thread to 'loan' you references to
> supporting ref-counted structures (vmspaces, creds, ...).  On a small
> scale, routines like 'copyin' and 'copyout' already follow the "must use
> curproc/curthread, so don't bother taking one on the command line"
> strategy.  If we were to assert that a certain class of functions always
> acted on behalf of the calling thread or process, that's not necessarily
> bad.  It might allow us to substantially simplify locking and reference
> handling, for example.

Regardless of how many angels that can dance on this pin, it
would be a good idea to document lock assumtions in and out
of all functions, using both comments and assert().

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message