On Fri, Oct 22, 2010 at 6:16 PM, Bulat Ziganshin wrote:

Hello John,

Monday, October 18, 2010, 8:15:42 PM, you wrote:

...

If anyone is listening, I would very much like for there to be a mechanism by which external functions can be called "unsafe"-ly, but without blocking all other Haskell threads. I have code that does this:

+RTS -N2

This doesn't work, which was why the OP asked in the first place. When a thread calls an unsafe foreign function, it blocks everything until that function returns.

On 23/10/10 17:42, Gregory Crosswhite wrote:

On 10/23/10 7:54 AM, John Lato wrote:

...

On Fri, Oct 22, 2010 at 6:16 PM, Bulat Ziganshin mailto:bulat.ziganshin@gmail.com> wrote:

Hello John,

Monday, October 18, 2010, 8:15:42 PM, you wrote:

...

If anyone is listening, I would very much like for there to be a mechanism by which external functions can be called "unsafe"-ly, but without blocking all other Haskell threads. I have code that does this:

+RTS -N2

This doesn't work, which was why the OP asked in the first place. When a thread calls an unsafe foreign function, it blocks everything until that function returns.

Is that true? The last time we discussed this in Haskell Cafe the conclusion I drew from the discussion was that unsafe foreign functions block the current thread but not any other thread.

The conclusion I drew was that "unsafe" foreign functions block the current "capability" (OS thread) and any "threads" (Haskell forkIO etc) currently scheduled on that capability, but other capabilities and threads continue executing as normal. Thanks, Claude -- http://claudiusmaximus.goto10.org

Hello Claude, Saturday, October 23, 2010, 11:57:23 PM, you wrote:

...

Is that true? The last time we discussed this in Haskell Cafe the conclusion I drew from the discussion was that unsafe foreign functions block the current thread but not any other thread.

The conclusion I drew was that "unsafe" foreign functions block the current "capability" (OS thread) and any "threads" (Haskell forkIO etc) currently scheduled on that capability, but other capabilities and threads continue executing as normal.

yes, it blocks entire capability but afaik only one haskell thread can be scheduled on some capability at any concrete moment -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 23/10/10 23:17, Donn Cave wrote:

Quoth Claude Heiland-Allen, ...

...

The conclusion I drew was that "unsafe" foreign functions block the current "capability" (OS thread) and any "threads" (Haskell forkIO etc) currently scheduled on that capability, but other capabilities and threads continue executing as normal.

... until GC time when all capabilities must be ready. (?)

If a trivial test program would help, here I call the sleep() function, which I believe on a POSIX platform suspends the thread until receipt of a SIGALRM.

I wrote a program which shows some interesting behaviour: ----8<---- {-# LANGUAGE ForeignFunctionInterface #-} module Main (main) where import GHC.Conc (forkOnIO, numCapabilities) import Control.Concurrent (threadDelay) import Foreign.C (CInt) import System.Environment (getArgs) foreign import ccall unsafe "sleep" sleep :: CInt -> IO CInt delayer :: Int -> IO () delayer n = do print ("delayer", n) threadDelay 100000 -- 10Hz delayer n sleeper :: Int -> IO () sleeper n = do print ("sleeper", n) _ <- sleep 1 -- 1Hz sleeper n main :: IO () main = do m <- (read . head) `fmap` getArgs mapM_ (\n -> forkOnIO n $ delayer n) [1 .. numCapabilities] mapM_ (\n -> forkOnIO n $ sleeper n) [1 .. numCapabilities - m] threadDelay 100000000 -- 100s ----8<---- $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.3 $ uname -a Linux zebimus 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64 GNU/Linux $ ghc -O2 -Wall -threaded --make DelayedSleep.hs $ ./DelayedSleep +RTS -N4 -S -RTS 3 [snip] ----8<---- By interesting I mean there is lots of output from the delayer threads on capabilities without sleeper threads (as you would expect), with the delayer threads on capabilities also having sleeper threads being much less frequent (as you might also expect). But then there are some long pauses where there is no output from any thread: my hypothesis is that the whole runtime is blocked waiting for all threads to be ready for GC (because +RTS -S shows some GC stats after the end of those pauses). Claude -- http://claudiusmaximus.goto10.org

On 10/23/10 2:33 PM, Brandon S Allbery KF8NH wrote:

I think they mean "please don't conflate `reentrant' with `blocking' in the FFI".

Not knowing much about the guts of GHC's implementation of the FFI, I wonder if there would actually be an implementational difference in distinguishing blocking calls vs calls with (potentially) callbacks, or if it's just a terminology problem. Also, we should be distinguishing between C functions which are non-reentrant ---and so we'd want to block all other GHC threads from calling it before the first invocation returns[1]---, vs when the GHC runtime doesn't get itself into a reenterable state before invoking foreign calls. [1] Presumably this should be considered a library problem (e.g., use locks) rather than an FFI problem per se. -- Live well, ~wren