addForeignPtrFinalizer

[Simon Marlow]

> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 9614 bytes
Desc: patch
Url : http://www.haskell.org//pipermail/ffi/attachments/20020927/0efd8b21/patch.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testfptr.hs
Type: application/octet-stream
Size: 259 bytes
Desc: testfptr.hs
Url : http://www.haskell.org//pipermail/ffi/attachments/20020927/0efd8b21/testfptr.obj