Re: cvs commit: src/sys/kern kern_proc.c

From: Julian Elischer (julian_at_elischer.org)
Date: 06/09/04

  • Next message: M. Warner Losh: "Re: dev_t / udev_t confusion ?" 
    Date: Wed, 9 Jun 2004 11:23:48 -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.0406091101160.57882-100000@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@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..

    _______________________________________________
    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"

  • Next message: M. Warner Losh: "Re: dev_t / udev_t confusion ?"

    Relevant Pages

    • Implementing expected core OS functionality
      ... Most documentation and sample code on Windows ... Dolphin provides a wonderful platform for studying the OS API ... might reference the particular API. ...
      (comp.lang.smalltalk.dolphin)
    • Re: Determine if an item in a collection has changed
      ... What people do with API - I don't know. ... >> parent, which by necessity holds a reference to each of its children (via ... >> hold its pointer. ...
      (microsoft.public.vb.general.discussion)
    • Re: Passing python list from C to python
      ... you are importing it from C, but importing it from Python [so that you ... Python/C API reference is 162 pages! ...
      (comp.lang.python)
    • Re: Framebuffer programming
      ... > Please give me the exact link so I may see that the correct URL is ... The new site does not appear to have an API ... >> reference. ... Since my knowledge of the framebuffer is currently ...
      (comp.os.linux.development.apps)
    • Re: "Cant return a temporary from lvalue subroutine..."
      ... A similar problem exists with objects that expose their interior though overloading a dereference operator, ... I have used tied hashes to correct this (that is, returned a reference to a tied hash in response to %, and haven't encountered the particular difficulty you're seeing. ... I wrote whole load of in-house classes that used this API technique and then had to labourously go through all our programs to use a direct method-call API rather than the overload-tie API. ...
      (comp.lang.perl.misc)