haskell finalisers driven underground
mivori at hotmail.com
Mon Feb 3 17:26:13 EST 2003
outlawing Haskell finalisers / eliding them from the language is a futile
it will just drive them underground like (using a previous example ) ....
>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
> x = sum [1..10000]
the result of this (using hugs) yields an error as expected ....
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
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
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*
More information about the FFI