Some thoughts on this, Whilst I agree that finalizers are best avoided, it must be possible to order the finalizers for running on exit... Perhaps a simple multi-pass algorith would do? (ie: run all finalizers that do not refer to other objects with finalizers - repeat until no objects with finalizers remain. What can be done about loops I am not sure (where A refers to B which refers to A and both have finalizers)... The alternative would seem to be writing your finilizers such that they first call the finalizers on any refered objects which haven't been finalized yet (In the case of loops if we specify running the finalizers on any objects refered to on which the finalizer has not been entered yet - it should work too) Whatever happens I think it must make sure all system resources allocated by a program are freed on exit - otherwise the machine will have a resource leak and will need rebooting eventually. Keean. Simon Marlow wrote:
The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr.
I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true).
Let me share with you something that I've come to appreciate over the last few years:
Finalizers are almost always not the right thing.
Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible.
Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users