Bug in touchForeignPtr?

[Keean Schupke]

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 at haskell.org
>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>  
>