[gclist] What does a garbage collector do about

[Greg Hudson]

On Sun, 2002-07-28 at 14:28, David Chase wrote:
> I am looking at this from the POV of someone providing libraries
> to clients.  If someone doesn't explicitly close the file, whatever
> might have gone bad on the close, is still out there.  The close is
> just the bearer of the bad news, and the problem was not avolded by
> not doing the close.

Yes, but you can recover from it gracefully, e.g. not report that a
piece of mail was successfully enqueued for delivery.

> In the case that you describe, I think that the AFS file objects
> should contain enough state to get new tokens and get the job
> done, if this is important.

Sorry to argue based on an esoteric example, but this makes no sense. 
AFS tokens are life-limited for security reasons; you would need the
user's password to get new ones.  Code which doesn't check close() error
codes runs the risk of not knowing when a file couldn't be written, and
perhaps acting on a bad assumption as a result.

> A failure on close in a finalizer
> is not appreciably worse than a failure on close in code that
> operates (generically) on "files".  The generic code is just
> as much in the dark.

Quite the contrary.  Only the code which performs an operation is in a
convenient position to recover gracefully from failure cases.  (Which is
why it can be so difficult to write robust code to recover from
spontaneous system crashes.)  Usually the most important action in a
recovery is to stop what you were doing--something you can't do from a
separate thread or from a destructor or finalizer.

> I think it is the best of the bad models currently available.  It replaces
> atrocities like signal handlers preempting the current thread, wherever
> it happens to be.

Eh?  Synchronous signal delivery doesn't require a multithreaded
programming model; it is just as compatible with (for instance) an
event-handling model.