cvs commit: src/sys/kern kern_proc.c

[Julian Elischer]

On Wed, 9 Jun 2004, Poul-Henning Kamp wrote:

> In message <Pine.BSF.4.21.0406091101160.57882-100000 at InterJet.elischer.org>, Ju
> lian Elischer writes:
> >
> >On Wed, 9 Jun 2004, Poul-Henning Kamp wrote:
> >> In message <Pine.BSF.4.21.0406091051580.57882-100000 at InterJet.elischer.org>, 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..