caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Damien Doligez <Damien.Doligez@inria.fr>
To: caml-list@inria.fr, skaller@maxtal.com.au
Subject: Re:  finalisation
Date: Fri, 4 Feb 2000 17:27:34 +0100	[thread overview]
Message-ID: <200002041627.RAA17717@tobago.inria.fr> (raw)

>From: skaller <skaller@maxtal.com.au>

>In Vyper, my ocaml based Python interpreter, I have now enabled
>python __del__ methods, which are finalisers for python class instances.
>CPython uses reference counting, and so it finalises an acyclic graph
>of objects top down: first the finaliser (__del__ method) of the root
>object is invoked, possibly causing some child object's ref counts
>to go to zero, in which case they're finalised recursively, then the
>attributes of the object are detached, causing all remaining child
>reference count to be decremented, possibly going to zero (and invoking
>finalisers).

If python specifies reference counting, I guess the only solution is
to implement reference counting.  You can use O'Caml's finalisers to
help you in the following way:

Add a reference count field to each finalisable object.  Initialise it
to 1 upon allocation and register a finalisation function for this
object.  Increment the reference count when you create a new reference
from another finalised object, and decrement it when you remove a
reference (you can do it by simply calling its finalisation function).

The finalisation function will do the following:

1. Decrement the reference count.
2. If the reference count is not 0, stop here.
3. Do your finalisation work for this object.
4. Call the finalisation function of each object that is referenced by
   this one.

The reference keeps track of other finalisable objets that point to
this one, plus one (the initial value) that keeps track of all other
pointers to this object, with the help of O'Caml's GC.


>An algorithm which finds a garbage object on which no other garbage
>objects depend (if any) can proceed to safely finalise that object.
>By applying this algorithm repeatedly to all garbage objects, a correct
>order of finalisation is found for acyclic graphs of objects.
>
>In principle, the garbage collector must already know how to do this,
>although I do not know the details enough to know if there is a
>convenient way to reuse existing code to sequence finalisers
>correctly in this case.

No.  The garbage collector never looks at the pointers between dead
objects.  That's one of the reasons why it is a lot more efficient
than reference counting.

-- Damien




             reply	other threads:[~2000-02-04 18:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-04 16:27 Damien Doligez [this message]
2000-02-04 18:36 ` finalisation skaller
  -- strict thread matches above, loose matches on Subject: below --
2000-02-03 14:06 finalisation skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200002041627.RAA17717@tobago.inria.fr \
    --to=damien.doligez@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=skaller@maxtal.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).