On Sat, Aug 21, 2010 at 10:58 AM, John Millikin <jmilli...@gmail.com> wrote: > I think the docs are wrong, or perhaps we're misunderstanding them. > Magnus is correct. > > Attached is a test program which listens on two ports, 42000 (blocking > IO) and 42001 (non-blocking). You can use netcat, telnet, etc, to send > it data. The behavior is as Magnus describes: bytes from > hGetNonBlocking are available immediately, while hGet waits for a full > buffer (or EOF) before returning. > > This behavior obviously makes hGet unsuitable for enumHandle; my > apologies for not understanding the problem sooner.
You should note that in ghc>=6.12, hWaitForInput tries to decode the next character of input based on to the Handle's encoding. As a result, it will block if the next multibyte sequence is incomplete, and it will throw an error if a multibyte sequence gets split between two chunks. I worked around this problem in Haskeline by temporarily setting stdin to BinaryMode; you may want to do something similar. Also, this issue caused a bug in bytestring with ghc-6.12: http://hackage.haskell.org/trac/ghc/ticket/3808 which will be resolved by the new function 'hGetBufSome' (in ghc-6.14) that blocks only when there's no data to read: http://hackage.haskell.org/trac/ghc/ticket/4046 That function might be useful for your package, though not portable to other implementations or older GHC versions. Best, -Judah _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe