[Haskell-cafe] Re: Threading and FFI

[Ben Franksen]

Yves Parès wrote:
> I've also discovered something interesting: when I link with the
> 'threaded' runtime, but let the program use only one core (with '+RTS
> -N1'), the problem disappears. How comes?
> The whole thing remains a mystery, because I think what I'm trying to do
> is quite common...
> 
> 
> Yves Parès wrote:
>> 
>> There is a minimal code which produces this issue:
>>  http://old.nabble.com/file/p27613138/func.c func.c
>>  http://old.nabble.com/file/p27613138/main.hs main.hs
>> 
>> 
>> Yves Parès wrote:
>>> 
>>> Well I tried both 'unsafe' and 'safe', and actually I saw no
>>> difference...
>>> Even with 'safe', I see a huge difference between calling a C function
>>> which sleeps and another which doesn't. When there is a sleep, the other
>>> thread is really slower (it just prints numbers, and I look at which
>>> pace they're displayed).

This is to be expected. From the docs
(http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Concurrent.html#10):

"The downside of having lightweight threads is that only one can run at a
time, so if one thread blocks in a foreign call, for example, the other
threads cannot continue. The GHC runtime works around this by making use of
full OS threads where necessary. When the program is built with
the -threaded option (to link against the multithreaded version of the
runtime), a thread making a safe foreign call will not block the other
threads in the system; another OS thread will take over running Haskell
threads until the original call returns. The runtime maintains a pool of
these worker threads so that multiple Haskell threads can be involved in
external calls simultaneously."

IIRC, with -threaded, the RTS spawns a separate OS thread for 'safe' foreign
calls _in addition_ to the OS threads used for Haskell code (the number of
which you give with the +RTS -N<n> option).

Cheers
Ben