caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Finalisers
       [not found] <200001160136.MAA04210@ruby>
@ 2000-01-16 13:17 ` skaller
  0 siblings, 0 replies; only message in thread
From: skaller @ 2000-01-16 13:17 UTC (permalink / raw)
  To: caml-list

  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




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2000-01-16 21:33 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <200001160136.MAA04210@ruby>
2000-01-16 13:17 ` Finalisers skaller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).