> > Alternatively, we could have an explicit operation
> >
> > runFinalizers :: IO ()
> >
> > which causes finalizers to run in a non-pre-emptive or
> > non-concurrent system.
>
> Of course, this solution is no use at all if your use of ffi is to
> pull a big mostly pure C library into Haskell.
True.
> On two separate occasions, I've added interfaces to image processing
> libraries where pretty much every function was pure (it either
> generated a fresh image or returned an Int, Float or whatever).
> Images tend to be big (640x400x24bits is 3/4 Mbyte) so a few dozen
> image processing steps might quickly use up a lot of memory - and in
> all that time you don't go anywhere near the IO monad.
Sure, but relying on ForeignPtrs and the garbage collector is quite
dodgy. To support this kind of use we'd have to be much stricter about
when finalizers are run: currently there's no guarantee about the
promptness of running the finalizer.
Not to mention the fact that there's no guarantee at all about whether
the garbage collector will detect that the ForeignPtr is unreachable
when you think it should be.
I think for these kind of applications using ForeignPtrs isn't the right
thing - you really want to do the allocation/deallocation explicitly in
the IO monad.
Cheers,
Simon
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
