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

  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