Hello Yves, Thursday, February 18, 2010, 2:10:42 AM, you wrote:
> Okay! So under UNIX, haskell threaded runtime uses pthreads, if I well > understood. not exactly. it still uses lightweight (green) threads, but starts additional OS threads as required to keep N haskell threads running. it's very smart > To sum up, in order to achieve what I want, I have no other choice than > compiling with '-threading' and importing as 'safe' the functions which can > make a 'sleep'. > Thanks! > Ben Franksen wrote: >> >> Yves Pares 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 Pares 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 Pares 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 >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > ----- > Yves Pares > Live long and prosper -- Best regards, Bulat mailto:bulat.zigans...@gmail.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe