it will just drive them underground like (using a previous example ) ....
import Foreign
foreign import ccall "wrapper" mkfoo:: (Ptr a -> IO ()) -> IO (FunPtr (Ptr a -> IO () ))
main = do
p <- mallocBytes 64
foo <- mkfoo (\y->print x)
newForeignPtr p foo print x
where
x = sum [1..10000]
Main> main
INTERNAL ERROR: freeMallocPtr
but the utility of haskell finalisers is such that wrapper code like the above is to be expected, which introduces it's own problems.
As far as I can see there are no gaurantees for safety using C finalisers as opposed to haskell finalisers so we may as well have the convenience of haskell finalisers.
on the finalisation issue, previouse memo's included ...
2) Block the finalizer until the main thread completes evaluation
just as GHC does.
Blocking the finalizer would require all Haskell implementations to
implement preemptive concurrency. This is thought to be an excessive
burden.
another memo had ...
c finalisers are good enough ....
I think both propositions bear further examination.
1) c finalisers are good enough...
are they ?
perhaps I need to justify why haskell finalisers will be driven
underground. suppose we have a c routine returning malloc'd
memory. Who is going to write a c routine just to free it ?
2) "preemptive concurrency an excessive burden",
is preemptive concurrency the only solution ? If it is in what sense is it an excessive burden ? From an implementation point of view or
from an operational point of view.
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
