[gclist] What does a garbage collector do about

[Fergus Henderson]

On 31-Jul-2002, David Chase <chase@world.std.com> wrote:
> At 11:48 AM 8/1/2002 +1000, Fergus Henderson wrote:
> >On 31-Jul-2002, Boehm, Hans <hans_boehm@hp.com> wrote:
> >> We all agree that file descriptors should be explicitly closed (or
> >> closed by a C++-style destructor for an object with a known lifetime)
> >> whenever possible.
> >
> >I don't agree with that.
> >
> >There's a fundamental difference here between file descriptors opened in
> >input mode, and file descriptors opened in output mode.
> >
> >For file descriptors opened in input mode, if the GC and file open routine
> >do a good enough job of reclaiming unreachable file descriptors so that
> >you won't run out of file descriptors, there's no need to explicitly
> >close them.
> 
> Mostly to be contrary, I'll disagree.  [...] "locked for input" [...]
> is the sort of error that I might expect to run into if
> GC and finalization were responsible for closing input files

OK, good point.  But that sort of problem is much less severe than failing
to report output errors.  Leaving unwanted read locks around for longer
than necessary is at worst a denial-of-service problem.  Failing to
report output errors, on the other hand, can lead to corruption of data,
which is far more likely to have serious negative consequences.

> I think the general rule to follow is that being a good citizen is
> desirable and should be attainable, but we should not expect
> perfection, and make use of tools (like GC) to smooth over the
> problems.

We should also make use of tools to *detect* such problems.  We should
not expect perfection, but our development model, development processes
and development tools should do the best they can to encourage it.

So, in debugging mode, finalizers for open output files should report
the problem (failure to explicitly close the open output file)
in a hard-to-ignore way, e.g. aborting the application.

In production mode, they should log such errors and then do their
best to continue (i.e. close the file).   Failure to explicitly close
the file should be treated as a programming error (and logged),
regardless of whether the close operation encounters an I/O error or not. 

Tools should be configured so that they default to debugging mode,
so that problems are reported rather than being smoothed over.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.