| For now, I resolved the finalizer issue by making the finalizers
behave
| approximately as in the non-threaded case.
| When the main action finishes, all finalizers are run one after
another
| (but in unspecified order), then the program exits. While the
| finalizers are being run, other haskell threads _continue to run_.
This
| seems ugly and dangerous to me, but a) it is the same in the
| non-threaded RTS and b) it's non-trivial to do it differently.
Hans Boehm (the world expert on this kind of stuff) gave a good talk at
POPL about finalizers. His paper "Destructors, finalizers and
synchronisation" is doubtless somewhere on the web; certainly it's in
the POPL proceedings.
He argues strongly that
there should be no system guarantee that
finalizers are run on program exit
His main reason is that there can be absolutely no guarantees about
ordering, so even if the finalizer wants to print something out, for
example, the stdout handle might have been closed. Finalizers that just
close open file handles aren't much of an improvement: the OS cleans up
anyway. Finalizers that do more are hamstrung by not knowing what else
has been finalized first.
He argues, too, that the programmer can control this stuff himself, by
running an explicitly-called clean-up routine to release external
resources (if that is needed).
Weak pointers can ensure that this clean-up routine does not keep the
resource alive.
So if we follow Hans's advice, you would not have to solve the awkward
problem you found. Java has already followed this course:
System.runFinalizersOnExit is now deprecated.
I'm not making a strong argument here.... just reflecting that your
difficulty and Hans's advice point in the same direction.
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
