caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ville-Pertti Keinonen <will@exomi.com>
To: Michael Walter <michael.walter@gmail.com>
Cc: caml-list@yquem.inria.fr, Jon Harrop <jon@jdh30.plus.com>
Subject: Re: [Caml-list] Re: exception safety / RAII ?
Date: Tue, 08 Mar 2005 13:33:12 +0200	[thread overview]
Message-ID: <1110281592.680.102.camel@localhost> (raw)
In-Reply-To: <877e9a1705030710476502ad31@mail.gmail.com>

On Mon, 2005-03-07 at 13:47 -0500, Michael Walter wrote:

> My O'Caml is not very fluent, possible "dispose resource" should read
> "resource # dispose". Basically, the idea is to deterministically
> clean up resources, as early as possible (yes, "but it's not as early
> as possible" is besides the point :-). In my experience this
> simplifies resource management and reasoning about it.

You're right, what you describe is often a good way of managing
resources and also standard practice in e.g. Common Lisp (your "using"
function looks a bit like unwind-protect).

In OCaml you need to know what function to use for disposal of the
specific kind of resource.  For the most general approach, you can pass
a function to call in order to dispose of the resource (making it even
more like unwind-protect).

> I have no idea about with finalizers in O'Caml (hence my more
> broad/general statement), but in other languages I've worked with
> there are several limitations which all basically origin in the fact
> that finalization order in these languages was non-deterministic.

This is also true in OCaml.

The current languages that I'm aware of in which people rely on
deterministic finalization are Python and Visual Basic.  In both cases,
it places nasty limitations on the implementation.

IMHO currently the closest to the "best of both worlds" is a good
garbage collector (with non-deterministic finalization) and explicit
management for those resources that need them (file handles are a good
example; in addition to the reasons already mentioned in this thread,
also because they may refer to sockets and to avoid running into file
descriptor limits).

I'm not sure I understand Jon Harrop's concern about using resources
after they've been deallocated.  This has been addressed in the obvious
way (return errors for operations on remaining references) in various
languages for decades, and unlike memory management and type errors,
AFAIK hasn't been a major source of bugs or complaints.



  parent reply	other threads:[~2005-03-08 11:33 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-05 18:16 Michael Benfield
2005-03-05 18:44 ` [Caml-list] " Gerd Stolpmann
2005-03-07  0:03 ` Jon Harrop
2005-03-07  1:32   ` Stefan Monnier
2005-03-07  2:48     ` [Caml-list] " Brian Hurt
2005-03-07 13:30     ` Jon Harrop
2005-03-07 14:37       ` Stefan Monnier
2005-03-07 17:10         ` [Caml-list] " Jon Harrop
2005-03-08 13:07           ` Damien Doligez
2005-03-08 21:56           ` Oliver Bandel
2005-03-09 13:34             ` Damien Doligez
2005-03-09 14:48           ` Stefan Monnier
2005-03-09 16:19             ` [Caml-list] " Jon Harrop
2005-03-09 22:45               ` [Caml-list] Re: exception safety / RAII Oliver Bandel
2005-03-09 23:42                 ` Charles Forsyth
2005-03-10 14:33               ` exception safety / RAII ? Stefan Monnier
2005-03-10 16:52                 ` [Caml-list] " Jon Harrop
2005-03-11 14:46                   ` Michael Walter
2005-03-12 22:54                   ` Stefan Monnier
2005-03-07 15:21       ` [Caml-list] " Michael Walter
     [not found]         ` <200503071729.20117.jon@jdh30.plus.com>
2005-03-07 18:47           ` Michael Walter
2005-03-08  1:10             ` Jon Harrop
2005-03-08 22:19               ` Oliver Bandel
2005-03-08 22:53               ` Daniel Yokomizo
2005-03-09  1:21                 ` [Caml-list] " Jon Harrop
2005-03-09 13:21                 ` Damien Doligez
2005-03-08 11:33             ` Ville-Pertti Keinonen [this message]
2005-03-08 12:32               ` [Caml-list] " Richard Jones
2005-03-08 14:17                 ` Michael Walter
2005-03-08 18:28               ` Jon Harrop
2005-03-08 21:34                 ` Damien Doligez
2005-03-09 15:05                 ` Stefan Monnier
2005-03-09 22:30                   ` [Caml-list] " Marcin 'Qrczak' Kowalczyk
2005-03-10 14:20                     ` Stefan Monnier
2005-03-08 21:32       ` [Caml-list] " Oliver Bandel
2005-03-07  3:31   ` [Caml-list] " Michael Walter

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=1110281592.680.102.camel@localhost \
    --to=will@exomi.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=jon@jdh30.plus.com \
    --cc=michael.walter@gmail.com \
    /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).