From: Andrew Martin <amartin@ibmoto.com>
To: caml-list@inria.fr
Subject: "C" Finalizers
Date: Wed, 10 Feb 1999 09:27:39 -0600 [thread overview]
Message-ID: <36C1A56B.3C6061B8@ibmoto.com> (raw)
Are there any restrictions on the things that a finalizer (the first
element of a block tagged with Final_tag) can do safely? For instance,
can it allocate memory from the Ocaml heap? Can it use callback to
apply a closure to a value? Is there any interest in exploring the
posibility of introducing a general-purpose finalization mechanism into
the Ocaml language itself ?
Why do I ask?
The reason is probably more academic than practical. I have become
curious about whether it is practical to write a BDD package in Ocaml.
Agreed, one would loose some efficiency over a "C" implementation. But
more critical to BDD performance than the constants involved in
accessing BDDs are the heuristics used for variable ordering etc. It
may be that a clear ocaml-style presentation is more amenable to
experimentation with reordering techniques and heuristics than a
necessarily complex "C" implementation. If so, this might ultimately
lead to a better performing package which could always be re-implemented
(at least partially) in "C" if you wanted to shave some time of the
constants.
Unfortunately, to track the improvement gained by re-ordering, you
really need to be able to know whether a node is referenced by the
outside world. While one could concoct various schemes involving arrays
of weak pointers to accomplish this, they all feel complicated and
contrived -- they very thing I was trying to avoid by writing in Ocaml
in the first place. The most natural way do deal with the problem is to
define a finalizer that recursively decrements ref counts.
Obviously, providing a general finalization mechanism in the Ocaml
language itself would be fraught with difficulty e.g. what's to prevent
the finalizer from creating new references to the object (and hence
indirectly to its descendants) that we just decided to free ? Still,
I thought I'd raise the issue and see if anyone is thinking about it.
Regards,
Andy Martin
--
Andrew K. Martin, Ph.D.
Motorola Inc., Somerset Design Center
Networking and Computer Systems Group
phone: (512) 424-8325 6200 Bridgepoint Parkway, Building 4,
fax : (512) 424-8846 Mail Drop OE70
email: amartin@ibmoto.com Austin, TX 78730
next reply other threads:[~1999-02-10 16:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-10 15:27 Andrew Martin [this message]
1999-02-14 1:39 ` doligez
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=36C1A56B.3C6061B8@ibmoto.com \
--to=amartin@ibmoto.com \
--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