From: Fabrice Pardo <Fabrice.Pardo@Lpn.cnrs.fr>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version)
Date: Mon, 10 Dec 2007 12:25:04 +0100 [thread overview]
Message-ID: <475D2210.70708@Lpn.cnrs.fr> (raw)
In-Reply-To: <95513600712091355j35c4fa65g40bbfce02303796a@mail.gmail.com>
Olivier Andrieu wrote:
>
> Well, not really: a GC manages memory, not OS resources like file descriptors.
> I wouldn't recommend relying on the GC to close those kind of resources.
>
> Write your code like this:
>
> let with_dir fname f =
> let d = Unix.opendir f in
> try let r = f d in Unix.closedir d ; r
> with exn -> Unix.closedir d ; raise exn
>
> once the "f" function returns, you directory handle is closed.
>
>
Thanks, this solution is clear and compact.
I think that all functions allocating resources out of the OCaml heap
should be documented as it, warning the programmer that
he should not be lazy, relying on automatic deallocation of resources.
The fact that Unix.opendir should be better documented
in that sense is marginal for me. It was only an example
of external C-allocated resource.
When using these kind of external C functions,
OCaml seems then less comfortable to the programmer
than reference counted languages.
The price to pay is not too high as functional code permit to encapsulate
the problem as shown by Olivier.
I have a new question now:
What is the drawback if we keep hidden
unsecure external functions (allocating out of the heap
resources, as Unix.opendir),
only publishing secure functions as "with_dir" ?
Of course, I mean other drawback than changing the API.
--
Fabrice
next prev parent reply other threads:[~2007-12-10 11:25 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 [this message]
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
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=475D2210.70708@Lpn.cnrs.fr \
--to=fabrice.pardo@lpn.cnrs.fr \
--cc=caml-list@yquem.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