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