> > Still hoping ;-) The discussion seemed to stop without reaching a > > conclusion last time. > > I thought it was concluded and the report changed such that all three > compilers which implement the ffi spec can implement it without > receiving a heart, lung and liver transplant.
Then I'll reformulate my question as a patch. Enclosed is a
proof-of-concept patch that implements Haskell finalizers in Hugs, which
works on some simple tests that I've run. There's nothing particularly
clever going on - I'm just suspending execution of the finalizers until
the next call to eval().
Is there anything fundamentally wrong with this approach? Possible
problems I can think of:
- It doesn't work too well with Hugs's cooperative multitasking:
don't try to synchronise with another thread from a finalizer.
The same problem occurs with foreign calls which re-enter haskell.
- It adds a small amount of overhead to eval(); I haven't measured
it, but I'm guessing it's not enough to worry about.
- If you refer to the ForeignPtr from the finalizer, then the
garbage collector will never discover the ForeignPtr is dead.
There are GC techniques to avoid this problem, though.
I've enclosed a simple test which runs finalizers within finalizers down
to an arbitrary depth.
Cheers,
Simon
patch
Description: patch
testfptr.hs
Description: testfptr.hs
