Foreign Function Interface (FFI)

[Wolfgang Thaller]

(follow-ups to the FFI list please)

Rafael Martinez Torres wrote:

> HI:
>
> Reading Haskell 98 FFI report, one question arised:
>
> Imported and declared a foreign function , via
>
> foreign import ccall foo:: IO(CInt)
>
> Is it guaranteed to be executed in atomic way ? I mean , should it
> block the whole STG system ?

No, it's not guaranteed to be executed atomically.
With current implementations, it does block the whole STG system, but 
only until a callback is made, and when multiple (forkIO'ed) Concurrent 
Haskell threads call foreign imported functions that might call back 
into Haskell, things become almost unpredictable.
GHC supports an optional feature (pass --enable-threaded-rts to 
configure when compiling GHC) that makes GHC guarantee that the STG 
system is never blocked by foreign calls. It will probably become the 
default in the future (after the remaining bugs are fixed).

> Idea: To implement a monitor , in a "external context" , and threads
> around him to access it, bypassing the Mvar paramter-pass among them...

Well, similar ideas have been brought up before, and I'm a bit 
sceptical:
*) Why should we introduce a feature at the language level for solving 
a problem that is already solved by MVars? You can write your own 
combinators to reduce the hassle of using MVars to a minimum.
*) Why would we want all external calls to be serialized? In most 
circumstances, I'd like more granularity than that.

What exactly do you have in mind?

Cheers,

Wolfgang