Foreign Function Interface (FFI)
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 ? Idea: To implement a monitor , in a "external context" , and threads around him to access it, bypassing the Mvar paramter-pass among them...
(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
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.
Firstly, thanks for your answer: I'm re-writting a Haskell-Maple library from Hans Wolfgang Loidl, basically adopting Haskell Posix Libraries and re-arranging concurrency issues around a Posix Pipe. I cannot send a URL since the code is a bit "unreadable", but it works... * From Haskell-Sequential, you don't neeed Mvars, since there are not forkIO'ds threads. * From a Haskell-Concurrent point of view, this is just to free the final Maple-Eden library user to consider concurrency uses, as the final signature should be: mapleEval :: String -> [MapleObject] -> MapleObject instead of mapleEval :: Mvar -> String -> [MapleObject] -> MapleObject However, this is not key... Programmer could make the effort for that. * The key problem arises now: We are programming on a Haskell-dialect parallel language, Eden, whose implementation extends that of Gph. There you have a Distributed Memory Model, each process ( process= set of "Concurrent threads" inside a processor-element) has its own heap,stack... Hence, every locally process has its own Mvar-state, and cannot be shared with other process-threads... It would have only sense on local heap, but you are not garanteed to run your process locally ( rather it will be remote ). That is because we need the "external context" monitor. Yes, we are forcing the language, I know... After all : import Concurrent newEmptyMVar :: IO(Mvar a) foreign import cgetMonitorMvar :: IO(Mvar a) are "safely" close under a monad , aren't they (*)? (*) Strictly speaking, we are storing/grabing (StablePtr a) to avoid the effect of the Garbage Collector
*) Why would we want all external calls to be serialized? In most circumstances, I'd like more granularity than that.
Yes, I agree with you,but just to get the effect of a "monitor", on a mutex region. Of course, it is not for large computations, just a little while
What exactly do you have in mind?
Cheers,
Also you.
participants (2)
-
Rafael Martinez Torres -
Wolfgang Thaller