From: John Skaller <skaller@maxtal.com.au>
To: caml-list@inria.fr
Subject: GC with finalisation?
Date: Tue, 24 Aug 1999 13:36:43 +1000 [thread overview]
Message-ID: <3.0.6.32.19990824133643.009a89a0@mail.triode.net.au> (raw)
I could use some advice on this. I'm implementing
a Python interpreter/compiler in Ocaml. Python class
instances support __del__ methods -- that is, destructors.
CPython uses reference counting for collection and finalisation.
JPython leverages Java's collector and finalisation semantics.
My current ocaml implementation leverages the ocaml collector,
which doesn't support finalisation (as far as I know).
I seem to have several choices.
1) implement reference counting for finalisation
* disadvantage: same problem as CPython: doesn't resolve
circular references properly
* disadvantage: overhead and coding complexity
* advantage: synchronous finalisation
2) Implement a full resource collector
* disadvantage: overhead and complexity
* disadvantage: probably won't support synchronous finalisation
3) provide BOTH reference counting and a collector (as Perl does)
* disadvantage: overhead and complexity
* advantage: finalises everything
* advantage: synchonous finalisation in all cases
that CPython provides it
I am interested in any comments on how to solve this problem.
Order of finalisation can be important in Python.
I have a major literate programming tool (Interscript) written in Python,
the compiler/interpreter is being built to make it go faster.
I use finalisation semantics extensively (tables of information
are generated at the end of document processing, etc).
While I might be able to rewrite it to avoid automatic finalisation,
it would be nice to support the wide class of other Python programs
that rely on it.
-------------------------------------------------------
John Skaller email: skaller@maxtal.com.au
http://www.maxtal.com.au/~skaller
phone: 61-2-96600850
snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia
next reply other threads:[~1999-08-26 17:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-24 3:36 John Skaller [this message]
1999-08-26 21:09 ` Markus Mottl
1999-08-27 5:10 ` John Skaller
1999-08-27 7:13 ` STARYNKEVITCH Basile
1999-08-28 4:29 ` John Skaller
1999-08-28 21:49 ` Markus Mottl
[not found] <3.0.6.32.19990830144523.00964e20@mail.triode.net.au>
1999-08-30 12:31 ` Markus Mottl
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=3.0.6.32.19990824133643.009a89a0@mail.triode.net.au \
--to=skaller@maxtal.com.au \
--cc=caml-list@inria.fr \
/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