reference counting.. continued..

[Julian Elischer]

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 at fledge.watson.org      Senior Research Scientist, McAfee Research
> 
> 
>