Date: Wed, 09 Jun 2004 20:58:57 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: reference counting.. continued.. Message-ID: <57800.1086807537@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 09 Jun 2004 11:49:05 PDT." <Pine.BSF.4.21.0406091147310.57882-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57800.1086807537>