The Revenge of Finalizers

[Simon Marlow]

> SimonM:
> > I can get it to fail another way too:
> 
> >   main = do
> >     p <- mallocBytes 64
> >     newForeignPtr p (print x)
> >     print x
> >    where
> >     x = sum [1..10000]

Alastair:
> The problem is probably this shared mutable variable used behind the
> scenes in the implementation of the numeric show code 
> (hugs98/src/printer.c)
> 
>   static Cell out;	/* GC'd var used by printer code   */
> 
> [It's also used if you use the -u flag to use Hugs' builtin printer
> instead of the Show function - but I don't think anyone does that
> anymore and we could probably kill that code without anyone noticing
> (???).  (Unless, does Hood or some such use it?)]
> 
> 
> I think all the functions affected return void so it'd be easy to
> replace the global variable with a local which is threaded through
> that set of functions.

My impression is that the problem is more fundamental: the thunk for x
is under evaluation when the finalizer begins to run, so it already has
a bunch of stuff on the stack.  The finalizer starts to run, and demands
the value of x - probably we shouldn't get a crash, but a blackhole
instead.  Fixing it so that the evaluation of x is actually continued is
what we want, but I can't see an easy way to do that.  

I suppose you could suspend either the finalizer or the main thread
using the trick of saving its stack on the heap - is this implemented in
Hugs?  

The only other solution I can think of is to delay finalizers until we
get back up to the IO monad.  Usual disclaimers apply: I have very
little idea how the Hugs backend works, so there might be another way
around this.

Cheers,
	Simon