IO-System

[Seth Kurtzberg]

In addition, not all the target environments have the same capabilities.  I/O 
may be from/to a file system, and so in systems with multiple file system 
types you can't even rely on a consistent set of capabilities at O/S 
granularity.

This is a big problem for me as I'm implementing my database engine, which 
must force writes to disk for transactional semantics.  The problem exists 
(as someone mentioned already) at the operating system level in many cases.

Even if a consensus could be obtained about what the "Right Thing" is (not 
impossible at least in principle :) ) it is probably not possible to 
implement ANY policy consistently in all current target environments.

On Monday 16 September 2002 21:41, Glynn Clements wrote:
> Sigbjorn Finne wrote:
> > > > Look at this small programm:
> > > >
> > > >     module Main(main) where
> > > >
> > > >     main = echoTwice
> > > >
> > > >     echo = getChar >>= putChar
> > > >
> > > >     echoTwice = echo >> echo
> > > >
> > > > while executing: the program reads first two chararcters and then it
> > > > writes the characters, but
> > > > in my opinion it would be right to read one character, then write one
> > > > characater, then read, then write.
> > > > What's the reason for it?
> > >
> > > Buffering.
> >
> > A deficiency of the current implementation of the IO system, I'd
> > say. Reading from stdin ought to force a stdout (and stderr) buffer
> > flush. The GHC IO libs used to do this.
>
> The equivalent ANSI C I/O functions typically flush either all
> buffered output streams or all line-buffered output streams whenever a
> read operation is passed to the underlying system call (but not when
> it can be satisified from the input stream's buffer).
>
> However, that won't make any noticeable difference unless the user
> explicitly puts the input stream into unbuffered mode. If the input
> stream is buffered, getChar doesn't (and shouldn't) return anything
> until Return (Enter, NewLine, ...) is pressed.
>
> > This is constant source of confusion for users & turning off
> > buffering alltogether is a poor substitute for having the IO
> > system do the Right Thing under the hood.
>
> The "right" thing is a subjective notion. GHC already has some "magic"
> behaviour in this regard; i.e. using:
>
> 	hSetBuffering stdin NoBuffering
>
> automatically changes the terminal settings (e.g. clearing the ICANON
> flag) if stdin is associated with a terminal.
>
> Even then, this won't "do the right thing" if the terminal itself (as
> opposed to the driver) is line-buffered; nothing will.
>
> A user who wants unbuffered input will probably argue that "the right
> thing" is to make stdin unbuffered by default (along with clearing the
> ICANON flag). OTOH, a user who wants line-buffered input (i.e. the
> ability to use BackSpace/Ctrl-W/Ctrl-U) will probably disagree.

-- 
-----------------------------------
Seth Kurtzberg
M. I. S. Corp.
1-480-661-1849