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
This archive was generated by hypermail 2b29 : Sun Jan 16 2000 - 22:48:09 MET