Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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





             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