On Sat, Aug 21, 2010 at 5:40 AM, Magnus Therning
It changes the timing. The iteratee will receive the data sooner (when it's available rather than when the buffer is full). This means it can fail *sooner*, in wall-clock time.
I still fail to see how this works. So I went to see the sources. In [1] we can see how hGet and hGetNonBlocking are defined. The only difference is that the former uses hGetBuf, and the latter uses hGetBufNonBlocking. [1] http://hackage.haskell.org/packages/archive/bytestring/0.9.1.7/doc/html/src/... hGetBuf's main loop is bufRead [2], while hGetBufNonBlocking's main loop is bufReadNonBlocking [3]. Both are very similar. The main differences are RawIO.read vs RawIO.readNonBlocking [4], and Buffered.fillReadBuffer vs Buffered.fillReadBuffer0 [5]. Reading RawIO's documentation [4], we see that RawIO.read blocks only if there is no data available. So it doesn't wait for the buffer to be fully filled, it just "returns the available data". Unfortunately, BufferedIO's documentation [5] doesn't specify if Buffered.fillReadBuffer should return the available data without blocking. However, it does specify that that it should be "blocking if the are no bytes available". [2] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO... [3] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO... [4] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO... [5] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO... So, assuming that the semantics of BufferedIO are the same as RawIO's, *both* are non-blocking whenever data is already available. None of them wait until the buffer is full. The difference lies in whether they block if there is no data available. However, when there isn't data the enumarator *always* wants to block. So using non-blocking IO doesn't give anything, only complicates the code. Am I misreading the docs/source somewhere? =) Cheers! -- Felipe.