The Revenge of Finalizers

Ross Paterson ross at soi.city.ac.uk
Fri Oct 18 11:55:27 EDT 2002


On Fri, Oct 18, 2002 at 04:38:24PM +0100, Simon Marlow wrote:
> > 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)
> > [...]
> 
> 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.  

It's both, I think -- I missed the evalWithNoError() in printer().
But if you bypass the builtin printer by replacing print x with
putStrLn (showInt x ""), you get an incorrect answer instead of the
expected black hole.



More information about the FFI mailing list