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 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.
Oh, I forgot to mention. Perhaps your bug is that you're using hGetBufNonBlocking, which isn't on Windows? Cheers, Simon