[gclist] Timeliness of finalization

[stuart]

> On Mar 29, 11:08am, stuart  (yeates) wrote:

> Are we talking about process crashes, thread crashes,  or OS/machine crashes?
>  It's awfully hard to run the finalizers after the power supply failed, or
> whatever, so I don't think the latter is possible.  The OS will have to make
> sure that the disk is always in a recoverable state, just as it does now.
> 
> Thread crashes don't really affect anything.  Process crashes might cause some
> synchronous cleanup action sto be invoked, and might remove some roots.  I
> don't understand why they would impose constraints on kernel finalization.

There are many situations in which an OS may attempt a graceful shut-down,
typically unavailability, pending unavailability or unreliability of a 
resource on which the kernel depends for internal consistency. These
include electric power, kernel binary and swap disks (and/or network
connection to same if served remotely), RAM integrity (excessive parity
errors) etc.

Consider the case of a power-manager, which senses has just been notified
of imminent failure of the power supply, This situation usually leads to 
the OS shutting down or crashing. If we are relying on finalisation 
to ensure closure of files/consistency of disks, to maintain contracts 
in a distributed environment or similar we still need to have our finalisers
invoked if at all possible.

> > Such a system might even be able to handle the case where a subsystem
> > throws an uncaught exception (caused by a hardware error or similar),
> > and other subsystems NEED to have their finalisers invoked.

> Could you clarify?  In a single address space system finalizers are not
> associated with subsystems.  They are associated with objects which may be
> referenced by multiple subsystems.

What I meant (but didn't make clear) was that a subsystem which generates
a fatal error has the option of performing finalising actions at the 
(informationally rich) point at which the error was generated, whereas 
other subsystems have no option but to rely on finalisers (which are 
relatively informationally poor).

For example a swap disk which detects unrecoverable error state can 
prepare itself for reboot before generating an error, rather than relying 
on a finaliser to do it. 

I was not suggesting calling finalisers only for some subsystems.

stuart





-- 
         stuart yeates <stuart@cosc.canterbury.ac.nz> aka `loam'
                  you are a child of the kernel space 
            no less than the daemons and the device drivers,
                   you have a right to execute here.