[gclist] What does a garbage collector do about

[Greg Hudson]

On Sat, 2002-07-27 at 17:33, David Chase wrote:
> However, if it happens that a file is not
> closed before all references are dropped, it seems unwise to
> simply leak the file descriptor.  999 times out of 1000, that
> file could have been closed without error, and not closing it
> is probably more wrong than closing it and discarding the
> occasional error.

This kind of reasoning tends to encourage code which only works 999 out
of 1000 times.  A leaked file descriptor is more likely to be noticed
than a bug which only manifests when, say, you're using AFS and your
tokens expire while you have a file open for writing.

Of course, my reasoning suggests that file objects should have
destructors which abort the program if the file hasn't been closed, to
make it most likely that the bug will be noticed early.  So perhaps this
isn't an argument against finalizers after all, just an argument that
finalizers should be restricted to invariant-checking.

> I don't think it is much of a problem.  If you were designing
> a language from scratch, there are even more possibilities for
> dealing with this -- for instance, the user could supply the
> thread for running finalizers, and thus have control of them.

This is an interesting possibility, but usually a separate thread
doesn't have the context to know what to do about a finalizer error.  If
you have trouble closing a file, it often means you have to gracefully
abort the operation you were doing at the time; it requires a lot of
extra state for the separate thread to know what that is.

Also, papering over an issue like this with multithreaded programming is
making a fairly big assumption--that multithreaded programming is a
viable model for maintainable code.  In my experience, that assertion is
unproven at best.