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
next prev parent 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