Guarantees regarding finalizers

Simon Marlow marlowsd at
Tue Dec 1 07:13:03 EST 2009

On 01/12/2009 11:25, Mietek Bąk wrote:
>> The docs are rather backward.  Foreign.ForeignPtr finalizers are guaranteed
>> to run, Foreign.Concurrent finalizers are not.  I'll fix the docs, thanks
>> for the report.
> Thanks for the reply.  Unfortunately, I'm running into the following
> error message when trying to use a Foreign.ForeignPtr finalizer:
> "foo: error: a C finalizer called back into Haskell.
>     This was previously allowed, but is disallowed in GHC 6.10.2 and later.
>     To create finalizers that may call back into Haskll, use
>     Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr."
> Is there a technical reason why the Foreign.Concurrent finalizers
> aren't guaranteed to run?

It's hard to make it work reliably, and arguably finalizers shouldn't be 
used in this way [1].

Haskell finalizers are run in separate threads, but separate threads 
don't normally prevent the Haskell program from exiting, so there would 
be an inconsistency if we made a special case for finalizers. Another 
problem is that you often find you need to express dependencies between 
finalizers, but that is not supported (the finalizers all run 
concurrently), and even if it were supported, it would probably be 
necessary to run the GC repeatedly until we run out of finalizers.


[1] "Destructors, Finalizers, and Synchronization", Boehm, Hans-J.

More information about the Libraries mailing list