| 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".
That's a positive advantage, provided there isn't a massive efficiency
cost. I'm all for nuking 'threadsafe' if we can!
| 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?
Would all these questions go away if we made safe=threadsafe?
| 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.
I don't think it was ever the intention that 'safe' should have a
guaranteed serialisation property. I think the idea was that
'threadsafe' was the most desirable, with 'safe' and 'unsafe' only
available for use if you wanted more efficiency and had some separate
guarantees that the extra efficiency was not at the expense of
correctness.
To be completely explicit, I think that increasing the safety level of
any foreign import should never make the program fail.
Simon
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
