Finalisers

[skaller <skaller@maxtal.com.au>]

  Short note to David: in ocaml 2.999 [with Gc.finalise function]:
> 
> I have used Gc.finalise in Viper to implement __del__ methods.
> A short test (create an instance of a python class with a __del__
> method, then forget it)  worked correctly.

	Thoughts:

> Suppose there are two objects, A and B, with a pointer
> in A to B but not vice versa.
> Suppose A becomes globally unreachable (and suppose
> B is thereby also unreachable).
> 
> It is important to run the finaliser for A before
> the finaliser for B in this case, since the finaliser
> for A can refer to B: B is reachable from A.
> Indeed, in Python's reference counting scheme,
> this behaviour is guarranteed.
> 
> Interscript _requires_ that this ordering apply
> to finalisation. In particular, when a weaver object
> is finalised, it generates the table of contents
> of some document, the output goes to file objects.
> It is important the file objects are not finalised
> until _after_ the weaver object has generated
> the table of contents.
> 
> In general, if A and B become unreachable, and there
> is a pointer from A to B, but not from B to A,
> then the finaliser of A must be run to completion
> before the finaliser for B is invoked.
> 
> This rule cannot be applied when there is a circular dependency:
> in that case, one can consider that it would be a programming
> error on the client's part to write finalisers that depended
> on the 'other' object's unfinalised state. [Since application
> of the rule would deadlock the finalisers, and neither
> would run -- leaving garbage around]
> 
> It is NOT clear to me why interscript would core dump
> if these semantics were not provided: it would fail
> to operate correctly (generate wrong output), but not crash.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller