On 18/04/2012 00:15, Paul Liu wrote:
Hi Simon,

Thanks for the explanation. So is this why there is a separation of
mkWeak# and mkWeakForeignEnv#, the latter being used for C finalizers
that is guaranteed to run before program quits?

Correct.

I wonder if it's possible to put some constraint to the type of
finalizers in mkWeak# so as to guarantee that it won't do nasty
things. Or maybe even get rid of the finalizer argument in mkWeak#,
since they are not guaranteed to run anyway.

As far as I know there is no good way to use the type system to enforce the kind of restriction we would need on mkWeak#. That's an interesting research question anyway.

Finalizers are still useful even when they are not guaranteed to run: typically you back up the finalizer with another mechanism (e.g. an exception handler) that provides the guarantee.

Cheers,
        Simon


Regards,
Paul Liu

On Tue, Apr 10, 2012 at 5:54 AM, Simon Marlow<marlo...@gmail.com>  wrote:
On 03/04/2012 21:40, Paul Liu wrote:

It seems to violate the claim that "all finalizers are run exactly
once" mentioned in the weak pointer paper. Is there any reason not to
enforce this?


GHC does do a GC before the program quits, but it doesn't wait for all the
finalizers to finish.  It turns out to be difficult to do that: the runtime
doesn't know the difference between a finalizer thread and an ordinary
thread, and we don't normally wait for ordinary threads to finish before
terminating the program.  What about blocked finalizers? What if the
finalizers create more finalizers?  It's all a bit of a swamp.  So now we
just don't guarantee that (Haskell) finalizers run before program exit; if
you want guaranteed execution then you can use C finalizers.

Some of the motivation for this change comes from Hans Boehm's seminal paper
on finalizers:

http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html

Cheers,
        Simon





_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to