Browse thread
Finalisers
- skaller
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@m...> |
| Subject: | Finalisers |
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