Potential Network SIG

[Simon Marlow]

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