safe and threadsafe
Hello Everyone,
I have recently spent some time improving GHC's support for
threadsafe foreign calls.
As a side effect of fixing a crashing bug, I made safe behave in
exactly the same way
as threadsafe. Now I have to document it... :-(
I'm not very happy with the current definition of safety levels in the
FFI addendum
(section 3.3, Import Declarations). So before I write up somethhing for
the GHC user manual
explaining how GHC interprets it and why it does so, I'll try to
convince someone to change
or at least clarify the FFI spec a bit:
First, some things that are unclear:
Are safe calls _guaranteed_ to block all other haskell threads and
prevent garbage collection,
or is that an implementation detail? Are unsafe calls guaranteed to do
so? {In a SMP implementation,
this might require additional interthread messaging}.
What should happen when C code running in a separate OS thread calls a
foreign exported
function while the Haskell Runtime is blocked on a safe call?
Some more points:
In what way can a safe call be considered safe in a multithreaded
environment? After all
it may cause very hard-to-predict blocking. I think that threadsafe
should be the default,
where available.
It _may_ be possible to implement safe in a way that is slightly more
efficient than threadsafe,
however this is relatively hard to do correctly in the context of GHC,
and I don't expect a big
performance gain. But if that is possible, then safe would be just a
hint for increasing performance
by sacrificing some safety. It should be renamed to something else.
Ceterum censeo that
threadsafe should be the default.
Some people have said that safe calls are intended for serializing
access to foreign libraries
that are not multithread-safe. I think that MVars should be used for
such purposes. Blocking the
entire Haskell Runtime for the duration of a safe call is overkill,
but it's not always enough:
Many old C libraries keep state in global variables from one call to
the next.
Cheers,
Wolfgang
--
ceterum censeo invocationes tutas esse delendas.
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Re: haskell finalisers driven underground
I think essentially there are only three ways you can have Haskell finalizers. (1) every FFI implementation must implement concurrency. I'm not convinced it must be preemptive, but at the very minimum you need some sort of concurrency, since you have some arbitrary number of finalizers (plus the main thread) all running together, all sharing the same space of potentially half-way evaluated values, and so all needing the ability to go to sleep and wake up whoever is half-way through evaluation. This is a problem for NHC, and possibly also for Hugs, so can't be done. However it is how GHC does it. (2) allow values to be evaluated more than once. This breaks various important compiler optimisations, and so right now is not an option for anyone. (3) delay the finalizers until there are no half-way-evaluated values. For example, for non-concurrent Haskells, immediately before or after a primitive IO action in the main trunk of a program (not inside unsafePerformIO !). This would work fine for many people, like me, but those purists who do very long pure computations without ever troubling the IO monad, impurists who run lengthy calculations inside unsafePerformIO, or statists who do lengthy computations in the state monad, may be surprised by the long delays before their finalizer gets run. At the moment the consensus seems to be not to have Haskell finalizer in the standard, but leave them up to the implementation. I think I'm secretly hoping NHC will implement (1) or (3), forcing Hugs to bow to market forces. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
