reference counting.. continued..

[John-Mark Gurney]

Robert Watson wrote this message on Sat, Jun 12, 2004 at 15:33 -0400:
> > 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.

In working on locking down KQ, I came across the same problem.  What I
ended up doing is creating an object that kept a copy of struct mtx *
in it.  When I created the object, you could either pass in a NULL, and
a fresh mutex would be created, or you could pass in your own object's
struct mtx *...  This makes it more capable of flexibility and only
requires a lock/unlocked arg...

Just a thought...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."