Endangered I/O operations

[Simon Marlow]

> Simon Marlow <simonmar@microsoft.com> writes:
> >
>  ....
> > You obtain the ordering properties by setting the handle to=20
> NoBuffering,
> > otherwise you get buffered input/output.  Wouldn't it be=20
> deviating from
> > the report to do extra flushing in the buffered case?
>=20
> The report is very silent about this, so I guess that reduces=20
> the question
> to what the end-user would prefer, (a) go non-buffered or=20
> make sure you
> call hFlush at the right time, or (b) have the IO=20
> implementation flush when
> required. I prefer (b), which is why I implemented this at=20
> the time, as it
> is
> more useable (and more efficient to boot).
>=20
> FWIW, notice that stdio implementations diverge on this issue too, all
> Win32 impls I've seen does the flushing for you, as did=20
> earlier impls of
> glibc, I seem to recall.

Ok, the concensus seems to be that folk would prefer the flushing to be
done automatically.  There's bound to be some overhead, though...

Cheers,
	Simon