Concurrency issue with dynamic linker in GHC
simonmarhaskell at gmail.com
Mon Oct 23 09:02:49 EDT 2006
Bulat Ziganshin wrote:
> Hello Vyacheslav,
> Monday, October 23, 2006, 7:20:47 AM, you wrote:
>>Bulat: I didn't get the chance to use the streams library yet, but
>>could you explain how it would solve my locking problem? The core
>>problem that the runtime under Win32 doesn't have an IO manager still
> i will say instead "ghc I/O library on windows doesn't include IO manager".
> there are 3 possible ways to implement I/O:
> 1) use read() calls marked as unsafe. it will block all haskell
> threads while one thread do I/O
> 2) use calls marked as safe. your I/O becomes fine
> 3) implement I/O manager which will make special asyncRead() calls and
> then wake up just the Haskell thread that completed its i/o. in terms
> of functionality, it's the same as 2), but a MUCH faster when you have
> a lot of I/O (imagine web server with thousands of threads running
> GHC i/o lib implements 3) on unixes but only 1) on windows. my Streams
> lib implement 1) on any system. BUT...
I beg to differ ;-) On Windows:
* reads are implemented by the RTS which provides non-blocking
I/O using OS threads. (see win32/IOManager.c etc.)
* reads are implemented with safe foreign calls, with no
special support from the RTS.
So you get non-blocking I/O in both cases on Windows. The lack of an I/O
manager thread doesn't affect the non-blockiness of I/O on Windows. It does
affect the efficiency: each blocked I/O request on Windows has an associated OS
thread, which gets quite expensive when you have a few of them. It also affects
signal handling (console events), which is what #637 is about.
More information about the Glasgow-haskell-users