[Haskell-cafe] Re: Network parsing and parsec

Keean Schupke k.schupke at imperial.ac.uk
Tue Sep 20 10:17:11 EDT 2005

Here's the code from hGetContents (base/GHC/IO.lhs):

    -- we never want to block during the read, so we call fillReadBuffer 
    -- is_line==True, which tells it to "just read what there is".
    lazyReadBuffered h handle_ fd ref buf = do
            (do buf <- fillReadBuffer fd True{-is_line-} (haIsStream 
handle_) buf
                lazyReadHaveBuffer h handle_ fd ref buf
            -- all I/O errors are discarded.  Additionally, we close the 
            (\e -> do handle_ <- hClose_help handle_
                      return (handle_, "")

So, it reads whatever is available, further description is available 
from the definition
of fillReadBuffered:

    -- For a line buffer, we just get the first chunk of data to arrive,
    -- and don't wait for the whole buffer to be full (but we *do* wait
    -- until some data arrives).  This isn't really line buffering, but it
    -- appears to be what GHC has done for a long time, and I suspect it
    -- is more useful than line buffering in most cases.

So for a disc buffer I would expect 1 complete buffer to be returned 
most of the time, for
a network read, I guess one packet (MTUs) worth should be expected...


Keean Schupke wrote:

> John Goerzen wrote:
>> On Tue, Sep 20, 2005 at 02:29:12PM +0100, Keean Schupke wrote:
>>>> It's unclear to me exactly how to mix the IO monad with Parsec.  It
>>>> doesn't really seem to be doable.
>>>> Not to mention that if hGetContents is used, the Handle has to be put
>>>> into non-buffering mode, which means one syscall per character read.
>>>> Terribly slow.
>>> Does it? I didn't think so ...
>> strace seems to say yes.
> Thats odd, the source code  seems to suggest that when you read past 
> the end of the buffer
> it reads the next entire buffer (it has cases for each possible buffer 
> configuration, line, block and none) - and I can think of no reason 
> _why_ it cannot use buffering... I would think that it's a bug if it 
> is the case.
>    Regards,
>    Keean.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list