Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
exception safety / RAII ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-03-09 (22:45)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] Re: exception safety / RAII
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.)