Concurrency issue with dynamic linker in GHC
simonmarhaskell at gmail.com
Mon Oct 23 09:05:56 EDT 2006
Simon Marlow wrote:
> 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
>> 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:
> 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.
Oh, I forgot to mention.
Perhaps your bug is that you're using hGetBufNonBlocking, which isn't on Windows?
More information about the Glasgow-haskell-users