Re: reference counting.. continued..
From: Julian Elischer (julian_at_elischer.org)
Date: 06/09/04
- Previous message: Julian Elischer: "Re: cvs commit: src/sys/kern kern_proc.c"
- In reply to: Poul-Henning Kamp: "Re: reference counting.. continued.."
- Next in thread: Robert Watson: "Re: reference counting.. continued.."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 9 Jun 2004 12:05:53 -0700 (PDT) To: Poul-Henning Kamp <phk@phk.freebsd.dk>
On Wed, 9 Jun 2004, Poul-Henning Kamp wrote:
> In message <Pine.BSF.4.21.0406091147310.57882-100000@InterJet.elischer.org>, Ju
> lian Elischer writes:
>
> >> Please, whatever you do, show that your API will deal with the
> >> refcounting of struct tty. Pay particular attention to the
> >> sysctl function which makes the difference between a CS-101
> >> assignment and the real world.
> >
> >yes this is the kind of thing that makes for 'fun'..
> >So, having just dealt with it,
> >how would you go about describing the general case that your example
> >falls into (for example if you were writing a textbook)?
>
> 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 simply do not belive that a "refcount API" will have that many uses
> in our kernel, most places we will have to hand-roll anyway.
>
> So before you spend too much time on this, I suggest you define
> what the API will look like, write the manpage and forget the
> implementation.
>
> Then use that definition to see how it would be used in actual
> kernel code.
>
> If the result of that is that code becomes more clear and easier
> to get correct for the programmers, then we can move ahead and
> see how to implement it, but if we end up with too many
>
> REF_YOU_CAN_NOT_REMEMBER_HOW_TO_USE_THIS(foo->ref, REF_MAGIC23)
>
> Then you can save the time spent thinking about the implementation.
I agree with this sentiment and I think I already mentionned that
the pivotal factor is whether there are enough cases in the kernel where
such an API could be used..
My gut feeling is that there are probably just enough to make it worth
while because of the number of times that I've implemented ref countes
and the number of times I've thought "There should be an API to do this
for me". However that is not a very scientific
basis, so definitly it is worht looking as a cross-section of all the
reference counts in the kernel.
>
> Poul-Henning
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Julian Elischer: "Re: cvs commit: src/sys/kern kern_proc.c"
- In reply to: Poul-Henning Kamp: "Re: reference counting.. continued.."
- Next in thread: Robert Watson: "Re: reference counting.. continued.."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
