I tell you what, I'll implement finalizer ordering if you guys implement full Haskell finalizers :-)
How about providing newForeignPtr as specified? (Or are you still hoping?)
Still hoping ;-) The discussion seemed to stop without reaching a conclusion last time. At least, I still don't think I fully understand why the current newForeignPtr is not implementable without concurrency, given that a form of context switching must already exist in order to implement foreign import that re-enters Haskell. Anyway, it's not that big a deal. I'll hopefully get round to making the change soon. Cheers, Simon
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.
At least, I still don't think I fully understand why the current newForeignPtr is not implementable without concurrency, given that a form of context switching must already exist in order to implement foreign import that re-enters Haskell.
We've written a bunch about it. I suspect that if we were to give a full and complete list of all the changes required we'd have done most of the work required to implement it (though not the work to debug and maintain it which is probably more significant). We're not going to do that so you'll have to live with the explanations we've given so far. -- A
On Thu, Sep 26, 2002 at 04:40:42PM +0100, Alastair Reid wrote:
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.
I'm a bit puzzled. Hugs has primitive newForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a) So what's wrong with newForeignPtr' :: Ptr a -> IO () -> IO (ForeignPtr a) newForeignPtr' p hf = do cf <- wrapFinalizer (const hf) newForeignPtr p cf foreign import ccall "wrapper" wrapFinalizer :: (Ptr a -> IO ()) -> IO (FunPtr (Ptr a -> IO ()))
So what's wrong with [...]
That would have the garbage collector invoking a C function (this is ok) which then calls a Haskell function (this is not and the ffi spec says not to expect it to work). Mutation cannot be overlapped with garbage collection. Things would be especially bad if the Haskell finalizer were to trigger garbage collection since then you have GC overlapped with GC - the GC is definitely not reentrant. -- Alastair
participants (3)
-
Alastair Reid -
Ross Paterson -
Simon Marlow