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.