On 10 Sep 2007, at 11:49 am, Neil Mitchell wrote:
Buffering, blocks and locks.
Buffering: getChar demands to get a character now, which pretty much
means you can't buffer.
Eh what? getchar() in C "demands to get a character now", which is
fully compatible with as much buffering as you want. In fact,
looking at the GHC 6.6 sources, I see that getChar -> hGetChar which
*does* do buffering.
Blocks: getContents reads blocks at a time from the underlying
library, whereas getChar has to do one character at a time.
Again, getchar() in C *returns* one character at a time, but gets
oodles of character from the underlying library (read(), as it happens).
As noted above, GHC 6.6 *does* read blocks from the underlying library.
Locks: getChar has to acquire locks, as does getContents. However,
because getContents can operate on blocks, this requires many fewer
locks.
What's to lock against? I'm writing single-threaded code. As for
getContents, "each time these lazy read functions are pulled on, they
have to check whether the handle has indeed been closed", which is not
entirely unlike locking.
While getContents / hGetContents is not defined directly in terms of
getChar / hGetChar, the implementation *does* do much the same things.
(Same blocking and buffering; for locks see previous paragraph.) So
it was natural to wonder whether the difference was in *my* code and
if so, what I was doing wrong.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
