Concurrency issue with dynamic linker in GHC

[Simon Marlow]

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
>>remains, correct?
> 
> 
> 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
> simultaneously)
> 
> 
> 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:

   without -threaded
     * reads are implemented by the RTS which provides non-blocking
       I/O using OS threads.  (see win32/IOManager.c etc.)

   with -threaded
     * 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.

   http://hackage.haskell.org/trac/ghc/ticket/637

Cheers,
	Simon