From owner-freebsd-arch@FreeBSD.ORG Sun Jun 13 01:00:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F24D16A4CE; Sun, 13 Jun 2004 01:00:01 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E74843D46; Sun, 13 Jun 2004 01:00:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040613005925012002eh9se>; Sun, 13 Jun 2004 00:59:26 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA07421; Sat, 12 Jun 2004 17:59:25 -0700 (PDT) Date: Sat, 12 Jun 2004 17:59:23 -0700 (PDT) From: Julian Elischer To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2004 01:00:01 -0000 On Sat, 12 Jun 2004, Robert Watson wrote: > > On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > > > I am not in favour of a dedicated API for refcounts. > > > > A dedicated API works if the refcount is a detached property of the > > object, and that is not normally the case outside OO+GC implementations. > > > > Our reference counts will almost invariably be integral properties of > > our objects and therefore has to interact with the remaining object > > locking. > > I don't have a strong feeling about the general need for a refcount API, > but I can confirm that many of the interesting objects in the kernel > wouldn't lend themselves to such an API. There are many cases where we'll > want to protect the reference count using an existing lock, in which case > locking built into the reference count API becomes a liability. Socket > reference counting is one example of this: in some ways, it's a general > purpose reference count, but the GC behavior is specific to sockets and > depends on additional uncounted references from file descriptors and the > prototocol layer. That's the problem... "uncounted references". Either you are counting references or you are not.. > > That said, I think making sure people get reference counts right is > important: at the very least, I think it would be useful to have a > refcount(9) man page with a well thought out example of a simple reference > count implementation, or a pointer at such an implementation (ucred isn't > bad). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Senior Research Scientist, McAfee Research > > >