Solution to finalisation problem [Re: fork()]
graham at sloth.math.uga.edu
Thu Jun 17 02:46:30 CEST 1999
Graham Matthews wrote:
: > All
: > objects will be in a state in which they can be finalised in pass 1 since
: > nothing is deleted in pass 1. I don't see the problem here at all.
Greg Ewing (greg.ewing at compaq.com) wrote:
: The only way I can see that the 2-pass collection scheme
: can fail is if the finaliser of object A destroys something
: needed by the finaliser of object B. But if each object
: having a finaliser looks after just one external resource,
: how can that happen?
What do you mean "destroy" here?
As I am sure Tim will tell you the only way a 2 pass collector can get
into trouble is if the finaliser for A changes some object O used by the
finaliser for B. In this case the ordering in which you run finalisers
is important. In other words a 2 pass collector solves the "which order
to finalise in" problem as long as finalisers don't change objects
used by other finalisers.
But here is where semantics comes into play. What do we want finalisation
to do? In my opinion finalisation should be *defined* as follows: all
objects collected by the collector are finalised *simultaneously*.
In implementation speak this means that objects are finalised relative to
the system state at the *beginning* of the finalisation process. This is
also relatively straighforward to implement I think. Alternatively we
can simply decide that finalisers that play with the state of other
finalisers are "wrong" programs and hence not worry about them. This is
much like the way Python treats threads playing with shared data (it's
up to the programmer to ensure that such code runs in a determinate
manner). Personally I think either solution is fine, since I do believe
that finalisers playing with the state of other finalisers is very rare,
and also "wrong" code.
As you grow up and leave the playground
where you kissed your prince and found your frog
Remember the jester that showed you tears
the script for tears
More information about the Python-list