RE: Waiting on Sockets or File Descriptors
On 02 February 2005 19:48, Peter Simons wrote:
Wolfgang Thaller writes:
a) poll() is not supported on Mac OS X and (at least some popular versions of) BSD.
Are you certain? Just tried "man poll" on one of the MacOS X machines the SourceForge compile farm offers, and that one had it: "Darwin ppc-osx1 5.5 Darwin Kernel Version 5.5".
b) 'forkIO' in the threaded RTS would suffice in this case, as the poll() or select() system calls don't use any thread-local state. In the threaded RTS, "safe" foreign imports never affect other threads [...].
That would be really good news! I assumed that GHC's runtime system used one thread for _all_ FFI invocations? (Unless you start new ones.) So I thought calling poll() would block all other FFI invocations until it returned?
Or is that only for "unsafe" FFI calls?
When you compile your program with -threaded, "safe" FFI calls don't block other threads, but "unsafe" calls still do. Basically a "safe" FFI call releases the lock on the RTS so other Haskell threads can continue to run (and that at least partly explains why we have the distinction: releasing and re-acquiring a lock is expensive).
Do you have an URL for me where I can find out more about this, by any chance?
There's not much, but the -threaded option is documented here: http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.h tml#OPTIONS-LINKER and the Control.Concurrent documentation explains what "bound" threads are. Cheers, Simon
On 02 February 2005 19:48, Peter Simons wrote:
Wolfgang Thaller writes:
a) poll() is not supported on Mac OS X and (at least some popular versions of) BSD.
Are you certain? Just tried "man poll" on one of the MacOS X machines the SourceForge compile farm offers, and that one had it: "Darwin ppc-osx1 5.5 Darwin Kernel Version 5.5".
"man poll" returns "No manual entry for poll" on my MacOS X 10.3.7
machine, Darwin 7.7.0. Nevertheless,
Simon Marlow writes:
When you compile your program with -threaded, "safe" FFI calls don't block other threads, but "unsafe" calls still do. Basically a "safe" FFI call releases the lock on the RTS so other Haskell threads can continue to run [...].
Thanks for the clarification. If I understood this right, then I can use forkIO to run a "safe" FFI function which blocks, but in the threaded RTS this will not block all other FFI calls. So what happens in the non-threaded RTS? Now the blocking yet "safe" FFI invocation _would_ block other FFI calls but not evaluation of "pure Haskell" code. Is that right? Peter
If I understood this right, then I can use forkIO to run a "safe" FFI function which blocks, but in the threaded RTS this will not block all other FFI calls.
Right.
So what happens in the non-threaded RTS? Now the blocking yet "safe" FFI invocation _would_ block other FFI calls but not evaluation of "pure Haskell" code. Is that right?
No. All execution of Haskell code is blocked, as there is really only one operating system thread in the whole system. Cheers, Wolfgang
participants (4)
-
Malcolm Wallace -
Peter Simons -
Simon Marlow -
Wolfgang Thaller