On 10/09/2009 16:05, Ian Lynagh wrote:
On Wed, Aug 26, 2009 at 05:42:19PM +0100, Simon Marlow wrote:
As far as buffering goes, Handles currently couple buffering modes, which is potentially frustrating if one wants, e.g., no buffering on recv, but block buffering on send.
Buffering is always invisible on input - if there is any input available, you'll see it immediately. It has performance implications only - but I can't imagine you'd want to deliberately reduce performance by turning off buffering (in fact, I think the new I/O library doesn't even honour NoBuffering on input Handles).
So is this program supposed to not be valid (or at least, to not behave as I would expect)?
import Control.Monad import System.Environment import System.IO import System.Posix.Process
main :: IO () main = do [get]<- getArgs hSetBuffering stdin NoBuffering when (read get) $ do x<- hGetChar stdin putStrLn ("Got: " ++ show x) executeFile "cat" True [] Nothing
With 6.8.2 I get:
$ printf "foo\nbar\n" | ./q True Got: 'f' oo bar
$ printf "foo\nbar\n" | ./q False foo bar
as expected, but with the HEAD:
$ printf "foo\nbar\n" | ./q True Got: 'f'
printf "foo\nbar\n" | ./q False foo bar
I think relying on NoBuffering in this way is a little dodgy. For example, how do you implement hLookAhead, or hIsEOF? Try your example with hIsEOF, and you'll probably get something "unexpected" with 6.8.2. Let's suppose we wanted this to work, i.e. not read more bytes than are necessary to satisfy the current demand. In the case of a multibyte character, we have to read one byte, notice that it is the first byte of a multibyte sequence, and then read the rest of the bytes (into a "buffer" presumably). It would be possible, but complicated, and I'm not convinced we really need to support this kind of usage. Cheers, Simon