On 07 November 2005 12:07, Donald Bruce Stewart wrote:
simonmar:
Finalizers aren't guaranteed to be run. In particular, if the main thread exits, then we don't run any outstanding finalizers. This change was made recently, but it turned out that even prior to 6.4 we couldn't guarantee to run all outstanding finalizers.
Does this explain it, or is there something else going on?
BTW, when you addForeignPtrConcFinalizer to a ForeignPtr created with mallocForeignPtr, you're *creating* a finalizer, it doesn't have one to start with. It's pretty expensive to do this.
Ah, right, I see. It's:
mallocForeignPtr = doMalloc undefined where doMalloc :: Storable b => b -> IO (ForeignPtr b) doMalloc a = do IO $ \s -> case newPinnedByteArray# size s of { (# s, mbarr# #) -> (# s, ForeignPtr (byteArrayContents# (unsafeCoerce# mbarr#)) (MallocPtrNoFinalizer mbarr#) #) } where (I# size) = sizeOf a
So the GC will take care of these thingies? Now, this probably means that the problem is somewhere else in Joelr's code.
Yes, mallocForeignPtr's are implemented using pinned GC'd memory, with no finalizer (unless you add one). That's why they're nice and fast. It looks like you have an old version of GHC.ForeignPtr there - it has a bug in it, please cvs update to the latest version. Cheers, Simon