From owner-freebsd-arch Wed Dec 13 7:39:29 2000 From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 07:39:27 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id C5DA137B400; Wed, 13 Dec 2000 07:39:26 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eBDFdMs27981; Wed, 13 Dec 2000 08:39:22 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200012131539.eBDFdMs27981@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Baldwin Cc: Garrett Wollman , arch@FreeBSD.ORG Subject: Re: An opaque refcount type In-Reply-To: Your message of "Tue, 12 Dec 2000 13:06:56 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Dec 2000 08:39:22 -0700 From: "Justin T. Gibbs" Sender: gibbs@aslan.scsiguy.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >It's opaque in the sense that a user doesn't know what it is inside it. This >means we can freely change around the implementation. For example, in the >INVARIANTS case it adds in lots of extra checks, but to ensure correctness, it >has to add in a mutex to use. My problem with it is that in the instances where you have to acquire a mutex anyway to manage the data, you will not want to use this interface. So, unlike say the LIST macros, there is no chance for our code to standardize on a single refcount API. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message