From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA06278 for caml-redistribution; Sun, 16 Jan 2000 22:44:40 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA11477 for ; Sun, 16 Jan 2000 21:37:39 +0100 (MET) Received: from ruby (scratchy12.zip.com.au [61.8.12.140]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id VAA25839 for ; Sun, 16 Jan 2000 21:37:32 +0100 (MET) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by ruby (8.9.3/8.9.3) with ESMTP id HAA05999 for ; Mon, 17 Jan 2000 07:40:02 +1100 Sender: weis Message-ID: <38822CA1.34B93687@maxtal.com.au> Date: Mon, 17 Jan 2000 07:40:01 +1100 From: skaller Organization: Maxtal X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Finalisation patch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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