From: STARYNKEVITCH Basile <Basile.Starynkevitch@cea.fr>
To: John Skaller <skaller@maxtal.com.au>
Cc: caml-list@inria.fr
Subject: Re: GC with finalisation?
Date: Fri, 27 Aug 1999 09:13:52 +0200 (MET DST) [thread overview]
Message-ID: <14278.15024.193052.853437@gargle.gargle.HOWL> (raw)
In-Reply-To: <3.0.6.32.19990824133643.009a89a0@mail.triode.net.au>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1919 bytes --]
>>>>> "John" == John Skaller <skaller@maxtal.com.au> writes:
John> I could use some advice on this. I'm implementing a Python
John> interpreter/compiler in Ocaml. Python class instances
John> support __del__ methods -- that is, destructors.
3 choices are then proposed. I suggest a fourth one:
4) patch the existing ocaml 2.02 garbage collector to allow finalized
objects containing (for example) a single Ocaml value:
this is not very difficult; you'll have to create a new tag, i.e. add
#define Finalwithvalue_tag 249
to mlvalues.h
then grep for Final_tag in the source, and add the case for
Finalwithvalue_tag (which should handle as value its second word
after the header, the first being the finalizer).
Notice that ocaml finalizer (including those alreday provided thru
Final_tag) should *not* allocate any value in the Ocaml heap (in
contrast with Java finalizers).
Your python finalizer could, for example, add the just finalized
Python object to a list -which is malloc-ed and free-d in C- (or
perhaps send it on a pipe to yourself) which should be scanned at
appropriate moments.
On the other hand, I consider that finalized objects supported by the
language (such as provided by Java & Python) are a mistake. In my
opinion, finalized objects should not have a user-provided finalizer,
but should only deal with system resources (file descriptors, X11
windows, coded only in C)
N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.
---------------------------------------------------------------------
Basile STARYNKEVITCH ---- Commissariat à l Energie Atomique
DTA/LETI/DEIN/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX * France
phone: 1,69.08.60.55; fax: 1.69.08.83.95 home: 1,46.65.45.53
email: Basile point Starynkevitch at cea point fr
next prev parent reply other threads:[~1999-08-28 17:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-24 3:36 John Skaller
1999-08-26 21:09 ` Markus Mottl
1999-08-27 5:10 ` John Skaller
1999-08-27 7:13 ` STARYNKEVITCH Basile [this message]
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=14278.15024.193052.853437@gargle.gargle.HOWL \
--to=basile.starynkevitch@cea.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