Date: Thu, 15 Nov 2001 12:24:45 -0800
From: Terry Lambert <tlambert2@mindspring.com>
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.
Message-ID: <3BF4248D.1735C282@mindspring.com>
References: <Pine.NEB.3.96L.1011115135118.1877C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BF4248D.1735C282>