From: Gordon Henriksen <gordonhenriksen@mac.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version)
Date: Mon, 10 Dec 2007 16:15:55 -0500 [thread overview]
Message-ID: <DB60F2B9-5665-45B4-8D0B-6BB1013617F4@mac.com> (raw)
In-Reply-To: <20071210202738.GA15084@furbychan.cocan.org>
[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]
On Dec 10, 2007, at 15:27, Richard Jones wrote:
> On Mon, Dec 10, 2007 at 05:33:21PM +0100, Oliver Bandel wrote:
>
>> Zitat von Fabrice Pardo <Fabrice.Pardo@Lpn.cnrs.fr>:
>>
>>> When using these kind of external C functions, OCaml seems then
>>> less comfortable to the programmer than reference counted languages.
>>
>> I doubt that reference-count is the reason here. perl also uses
>> reference count, but Filehandles and Dirhandles have to be closed
>> with close / closedir.
>
> This isn't true. In Perl file handles are closed at the end of a
> scope if they are no longer used. In other words a Perl-equivalent
> to this loop will never use more than a single file descriptor:
>
> while (true) {
> open "foo"
> }
>
> Even in a GC'd language which could finalize the file handle you
> could never be sure when the GC is going to be called so it could
> use an indefinite number of file descriptors.
>
> There is a really good paper on this subject -- how ref counting and
> garbage collection are orthogonal language concepts -- but I can't
> find it right now.
True. To address the original point, however:
This is a significant problem that crops up frequently in language/
runtime designs, especially when migrating to static, garbage
collected runtimes from scripting runtimes. parrot tackled this
problem; they call it timely collection and went far out of their way
to implement it, performing miniature collections when a resource
variable goes out of scope. This is rather expensive.
The practical reality is that, short of re-engineering memory
management, developers migrating from C++ (RTTI) and scripting
languages may need to retrain themselves to recognize that:
finalization does not provide a time bound on destruction
garbage collection manages memory and no other resources
C# provides a convenient using construct to ease the pain, but Java
code is littered with finally blocks for this reason.
Ocaml is hampered in that its try block has no native finally
construct, which requires repetition in the normal flow-of-control and
exceptional cases. Implementing reusable using constructs with filters
and closures for each type of resource is the best option I've seen,
although a generic finally construct is also possible also using
closures:
let finally expr cleanup =
try
let result = expr () in
cleanup ();
result
with x ->
cleanup ();
raise x
Unfortunately, this is not at all attractive at the call site.
— Gordon
[-- Attachment #2: Type: text/html, Size: 10331 bytes --]
next prev parent reply other threads:[~2007-12-10 21:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-09 21:39 Fabrice.Pardo
2007-12-09 21:55 ` [Caml-list] " Olivier Andrieu
2007-12-10 11:25 ` Fabrice Pardo
2007-12-10 12:03 ` Michaël Le Barbier
2007-12-10 16:33 ` Oliver Bandel
2007-12-10 20:27 ` Richard Jones
2007-12-10 21:05 ` Oliver Bandel
2007-12-10 21:15 ` Gordon Henriksen [this message]
2007-12-10 22:13 ` Oliver Bandel
2007-12-10 22:59 ` Jon Harrop
2007-12-10 23:29 ` Jon Harrop
2007-12-11 2:03 ` Yitzhak Mandelbaum
2007-12-15 21:33 ` Oliver Bandel
2007-12-16 15:14 ` Jon Harrop
2007-12-10 23:24 ` Jon Harrop
2007-12-09 21:57 ` Oliver Bandel
2007-12-09 22:12 ` Jon Harrop
2007-12-09 22:34 ` Oliver Bandel
2007-12-09 22:16 ` Oliver Bandel
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=DB60F2B9-5665-45B4-8D0B-6BB1013617F4@mac.com \
--to=gordonhenriksen@mac.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