caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: michael.le_barbier@laposte.net (Michaël Le Barbier)
To: Fabrice Pardo <Fabrice.Pardo@Lpn.cnrs.fr>
Cc: 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 13:03:12 +0100	[thread overview]
Message-ID: <86zlwi92pr.fsf@Llea.celt.neu> (raw)
In-Reply-To: <475D2210.70708@Lpn.cnrs.fr> (Fabrice Pardo's message of "Mon\, 10 Dec 2007 12\:25\:04 +0100")

Fabrice Pardo <Fabrice.Pardo@Lpn.cnrs.fr> writes:

> 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.

A drawback is that careful management of these ressources is no more
possible. If the choices made by module designer to ensure security do
not fit well your problem, you are left with no option other than
writing poorly behaving applications.

In contrast, given a module that delegates ressource management to its
users, it is fairly trivial to wrap modules's functionnalitites into a
module that automatizes ressource management in a way that will fit
many uses.

One would write an `EasyLazyUnix', `CookedUnix' or `UnixChest' module
with automatic deallocation of ressources.
-- 
Cordialement,
Michaël LB


  reply	other threads:[~2007-12-10 11:57 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 [this message]
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=86zlwi92pr.fsf@Llea.celt.neu \
    --to=michael.le_barbier@laposte.net \
    --cc=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;
as well as URLs for NNTP newsgroup(s).