Finalisation patch

From: skaller (skaller@maxtal.com.au)
Date: Sun Jan 16 2000 - 21:40:01 MET

  • Next message: Ian Zimmerman: "Re: Dynamic loading and building of shared libraries"

    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