| Sorry for not being more explicit: I should have added that the
| alternative solution I had in mind was to pass the object as an
argument
| to the finalizer. Clearly the finalizer needs to get access to the
| finalized object, but there also seem to be cases where the finalizer
| should be able to reference other objects in a non-weak way, so as to
| impose an order on finalization. Of course if you do ordering this
way,
| then it takes N full GCs to fully finalize a dependency chain N deep
(at
| least in our implementation).
Hmm. Yes, I guess we could change mkWeak (the fundamental primitive)
from
mkWeak :: k -> v -> Maybe (IO ()) -> IO (Weak v)
to
mkWeak :: k -> v -> Maybe (k -> IO ()) -> IO (Weak v)
and make the finaliser into a strong retainer rather than a weak one
(i.e. it keeps
alive the stuff it points to).
But then if two finalisers each referred to the key object of the other,
they'd keep each
other alive. Well maybe that's ok.
We still have the problem that the key value gets resurrected, so it can
be passed to its finaliser. But while it was moribund we may have
scheduled the finalisers of objects it
points to. Finalisers are just a mess.
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
