caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@jdh30.plus.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Re: exception safety / RAII ?
Date: Tue, 8 Mar 2005 01:10:21 +0000	[thread overview]
Message-ID: <200503080110.21839.jon@jdh30.plus.com> (raw)
In-Reply-To: <877e9a1705030710476502ad31@mail.gmail.com>

On Monday 07 March 2005 18:47, Michael Walter wrote:
> On Mon, 7 Mar 2005 17:29:19 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > Would you mind elaborating a little on what you do desire, i.e. what does
> > "using" do in C#, when would you use it and how does this relate to
> > OCaml?
>
> Sure. I hope the following answers all three questions at once:
>
> let using resource thunk =
>   try
>     let
>       result = thunk resource
>     in
>       dispose resource;
>       result
>   with
>    any_exception ->
>      dispose resource;
>      raise any_exception
>
> My O'Caml is not very fluent, possible "dispose resource" should read
> "resource # dispose".

Either is clear enough.

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

Yes, so you can use your code to do this in OCaml. My concerns with such code 
basically revolve around the possibility of incorrectly deallocating an 
external resource and then using it again. This is not possible if you rely 
on the GC but, as you say, the problem is then the lack of guarantees about 
when resources have been deallocated by what point in the code.

Perhaps explicitly asking the GC to deallocate all such resources is a better 
solution? Depending on the circumstances, this could give a big performance 
hit though...

> > Presumably this is only difficult in the more complicated case of a
> > general dependency graph between objects? In particular, one which has
> > cycles. What kinds of programs require such sophistication?
>
> 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.

Ok, I have found that, with a little thought and careful design beforehand, 
this is not a problem in OCaml. In the case of DAG dependency graphs, my 
solution is to represent the dependency graph for the GC by maintaining a 
list of references to dependees in each object. This forces the GC to respect 
dependencies when collecting.

If the dependency graph is allowed to contain cycles then this might not work. 
I'm not sure though.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists


  reply	other threads:[~2005-03-08  1:09 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 [this message]
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             ` [Caml-list] " Ville-Pertti Keinonen
2005-03-08 12:32               ` 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=200503080110.21839.jon@jdh30.plus.com \
    --to=jon@jdh30.plus.com \
    --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).