From owner-cvs-all@FreeBSD.ORG Wed Jun 9 18:24:19 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC65916A4CE; Wed, 9 Jun 2004 18:24:19 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5926243D2D; Wed, 9 Jun 2004 18:24:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <2004060918234901100fn8dle>; Wed, 9 Jun 2004 18:23:51 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA58947; Wed, 9 Jun 2004 11:23:50 -0700 (PDT) Date: Wed, 9 Jun 2004 11:23:48 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp In-Reply-To: <57019.1086804305@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 10 Jun 2004 11:36:34 +0000 cc: arch@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_proc.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:24:20 -0000 On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > > > >On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > >> In message , Ju > >> lian Elischer writes: > >> > >> >As I've said before and will continue to say.. > >> >"We need a more formal model of dealing with reference counts" > >> > > >> >i.e. > >> > > >> >we should get a set of reference counting primatives and make it WELL > >> >DOCUMENTED as to how they should be used.. > >> > >> And as others have replied: It is seldom worth it from code clarity > >> or performance wise. > > > >few have replied in that way.. > >most have agreed that it is worth persuing.. > > Then do so :-) I do actually agree that a general purpose reference counting API is very difficult to use in every situation and that there are situations where you just HAVE to roll your own.. The question is whether there are enough "simpler" cases around to make it worth spending resources on making an API to use.. several possible points that need to be kept in mind that have complicated my previous attempts to do so are: If you reference count EVERYWHERE, then you need to be able to add and subtract references very cheaply because you might end up doing it a lot. You also need to consider than in the kernel, the last referenc to somethign could easily occur in an interrupt routine, so the 'free' actions need to either be runnable at that time, or a mechanism needs to be developed to defer teh actual freeing to another time. Anyhow if anyone is interested I'll take this to -arch..