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
On Fri, Sep 27, 2002 at 12:25:31PM +0100, Simon Marlow wrote:
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().
It seems to have problems if more than one finalizer is pending, probably because runIO() calls eval(): t = do sequence_ (map f [1..30]) performGC where f n = do p <- mallocBytes 64 newForeignPtr p $ do free p putStrLn ("finalize " ++ show n)
Then I'll reformulate my question as a patch. [...] Is there anything fundamentally wrong with this approach?
I still maintain that getting this to work, testing it and, especially, maintaining it is a lot of work. [For example, you mention that finalizers that point to the object they finalize don't work. I guess we could fix that by adding GHC-style WeakPtrs.] I don't think it's appropriate to add that burden just so we can call free at the right time. We have a simple problem, there should be a simple solution. A
participants (3)
-
Alastair Reid -
Ross Paterson -
Simon Marlow