[Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative
felipe.lessa at gmail.com
Sat Aug 21 08:24:32 EDT 2010
On Sat, Aug 21, 2010 at 5:40 AM, Magnus Therning <magnus at therning.org> wrote:
> 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  we can see how hGet and hGetNonBlocking are defined. The only
difference is that the former uses hGetBuf, and the latter uses
hGetBuf's main loop is bufRead , while hGetBufNonBlocking's main
loop is bufReadNonBlocking . Both are very similar. The main
differences are RawIO.read vs RawIO.readNonBlocking , and
Buffered.fillReadBuffer vs Buffered.fillReadBuffer0 . Reading
RawIO's documentation , 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  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".
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? =)
More information about the Haskell-Cafe