caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Re: exception safety / RAII
Date: Wed, 9 Mar 2005 23:45:31 +0100	[thread overview]
Message-ID: <20050309224531.GE321@first.in-berlin.de> (raw)
In-Reply-To: <200503091619.40419.jon@ffconsultancy.com>

On Wed, Mar 09, 2005 at 04:19:40PM +0000, Jon Harrop wrote:
> On Wednesday 09 March 2005 14:48, you wrote:
> > >> Very rarely having problems with something can't save it from being
> > >> a very bad practice.  Not explicitly closing your files is (in 99% of
> > >> the cases) just sloppy coding.
> > >
> > > If we're talking about programs which are expected to run for an
> > > arbitrary amount of time (servers, the top-level etc.) then yes.
> 
> My statements were based on the incorrect assumption that the OCaml GC closes 
> files when it collects file handles. As this is not the case, I definitely 
> agree with you that not explicitly closing files in OCaml is sloppy coding 
> because they will not be closed implicitly.
> 
> However, provided you don't need to make any guarantees about when the file is 
> closed during the running of the program, I still think that implicitly 
> closing a file (or deallocating an external resource) via the GC is not 
> sloppy coding. Indeed, this facility can be very useful and can eliminate an 
> important class of run-time errors.
> 
> > This logic is routinely used in C to simply never call `free' because they
> > only run for a short time.  That's a textbook example of "sloppy coding".
> 
> I wouldn't advocate never calling free() in a C program, but what is the 
> difference between calling free at some unspecified point in the future and 
> relying on a GC?

I'm not a GC-expert, but it seems obvious to me, that a GC frees
ressources at unspecified time and that also means at unspecified
time in respect to the code that is executed.

But calling a free() at a certain point in a program means that the
deallocation is done at a certain time (in respect to code
that is executed, even when not in certain real time in seconds).

So, a free() in C is not unspecified, as it is called at a certain
section of code.

The GC frees ressources not as long as they are in use, but
that they are not in use does not mean that they are *immediately* freed
by the GC.
It depends on statistical/stochastical things (not to determine).
And that's the difference.

To say a GC that it has to free ressources immediately,
something like a GC-free-flush or something like that
seems a littlebid like going back to free().
(Well, it's not the same, because the GC handles the
"references" of which values are needed and which are not needed
anymore, so a trigger to the GC to free ressources is not the same
as writing code in C that does a free()-call. But normally
it should be easier programming when the programmer does not necessarily
have to think about freeing of GC-ressources.... normally the
GC should be intelligent enough to handle it by itself.)

(Rare cases may be there, where it is necessary to invoke
 GC-specific functions.)

Ciao,
   Oliver


  reply	other threads:[~2005-03-09 22:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-05 18:16 exception safety / RAII ? 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               ` Oliver Bandel [this message]
2005-03-09 23:42                 ` [Caml-list] Re: exception safety / RAII 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             ` [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=20050309224531.GE321@first.in-berlin.de \
    --to=oliver@first.in-berlin.de \
    --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).