FinalizeOps0Doc.tioga
Copyright Ó 1989 by Xerox Corporation. All rights reserved.
Written by: Christian Jacobi, December 1, 1989 4:21:07 pm PST
Christian Jacobi, July 21, 1992 2:34 pm PDT
This package is outdated; ChJ July 21, 1992
THE FinalizeOps0 INTERFACE
FinalizeOps0
Documentation for the FinalizeOps0 Interface
Christian P. Jacobi
© Copyright 1989 Xerox Corporation. All rights reserved.
Abstract: Implements some patterns how to deal with finalizable objects.
Created by: Christian P. Jacobi
Maintained by: Jacobi.pa
Keywords: finalization, package-refs, garbage-collection
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
Documentation
Please read the definitions module
Implements some patterns how to deal with finalizable objects. This package provides help for implementing some "medium level" complexity patterns for finalization. Trivial usage might, more complex usage must be done with PFinalize directly.
A method to create finalizable objects and put these into a table without the table preventing the finalization of the objects.
Passing of an extra ref to the finalization procedure.
Avoid using a process for the finalizations.
Design ideas, rationale and implementation tricks
I'm not so sure whether this package will make it or not; lets give it a try.
It has been designed with a particular application in mind: Avoid duplication of font information when multiple clients request the same font (for the X window software). It has also also been used for simpler cases, but mainly because it is already imported and then does not add the cost. But anyhow, it is a pretty cheap module.
If this module gets more clients I want to hear about; I then might be willing to really support it.
The design reason the simpler cases have been included in the package: Mainly reducing number of packages, and: as the package says:
1: don't use other finalization methods to revive objects handled by this package; this package wants to be sole finalization player for its objects.
By using the same package and context type for the simpler case, the programmer simply can not make the kind of errors this restriction is outlawing.
The restriction above and the exclusion of circular finalizable structures is NOT a reason to prefer usage of PFinalize over usage of this package: Probably those restrictions also hold to all the other packages; FinalizeOps only spells them out.
The fact that Context is a ref ref turns out very neat
1) It allows clients to use NARROW on Context but nevertheless uses an opaque type.
2) It allows to keep "package" refs to ContextImpl and have Context themselfs finalizable. Actually FinalizeOps is implemented itself using FinalizeOps.
I had real fun implementing this module; I have used some interesting tricks I consider fun:
1) Recursive implementation: FinalizeOps.Context is finalized itself with FinalizeOps. (While this proves not to be really saving much implementation cost, it is conceptionally nice.)
2) Avoidance of memory allocations in frequent case.
3) Monitor locking on arbitrary keys. Monitor locking is carefully designed: Creation of an object does not block creation of an object with a different key; even on the same context.