Reference-counting and finalizers that can fail are uneasy partners (was: [PATCH 0/4] qemu-img: Fix exit code for errors closing the image)

[Markus Armbruster <armbru@redhat.com>]

A half-baked thought has been sloshing around in my head.  Perhaps I can
bake it some more by writing it up.

Reference-counting and finalizers that can fail are uneasy partners.

When managing lifetimes manually, you control where finalization
happens.  When finalization can fail, you're as empowered as you could
be to make it fail in a place where you can handle the failure sensibly.

Manual resource management is tedious and error prone, and that's a
serious problem.  Garbage collection takes it off your hands.  Good.
But now finalization happens at some future time, and in garbage
collection context.  Fine when finalization's side effects are
sufficiently harmless.  But what if finalization can fail?  We trade one
serious problem (manual resource management) for another one (handling
finalization failures).

Reference counting is slightly different.  Here, finalization can only
happen at unref, which means you retain more control than with garbage
collection.  However, we do need unrefs in places where we can't
sensibly handle failure.  For instance, when code operates on an object
whose reference count can be dropped concurrently, we need to guard with
a ref/unref bracket to keep the object alive while the code is messing
with it.

The only way out I can see is to systematically avoid finalizers that
can fail, by extracting the part that can fail into a shutdown method,
to be called in a suitable context, and before finalization.

Yes, this takes us back to manual resource management, only we manage
shutdown instead of death.

Finalizing something that has not been shut down would be a programming
error.  A recoverable one, I guess; we can have finalize attempt to shut
down then, and if it fails, just weep into the logs and move on.

We gain a "shut down" state, and new problems may well come with it.