In finalise.c (ocaml 2.999 :-) the code is arranged to call finalisers
in order that they're specified by the client, which is usually
the _wrong_ order. If you consider some object P with a pointer
to an object C, usually C will be constructed first, then P.
This would call a finaliser on C before a finaliser on P,
which is wrong.

This particular problem is easily fixed by scanning
old values in 'final_update' in reverse order.

Unfortunately, while that will work in many cases,
it will not work when a child of an object (which must
always be finalised after the parent) is constructed
after the parent.

What we need here is a way for the client to specify
the order of finalisation, if the default first in last out
(stack) order is incorrect. 

I think we can consider the problem in terms of an
graph of finalisers [invocations of Gc.finalise].
There is a problem here, though: the client cannot
access the finalisers, except when Gc.finalise is called.

Hmmm. I'll have to think on this. At a minimum, acyclic
dependencies between objects must be correctly resolved.
[This is far from perfect, but much better than the current
scheme which is more often wrong than not]

-- 
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