Aleksandar Donev wrote:
> James Giles wrote:
>
>> But, I didn't propose that unbuffered I/O be provided. I proposed that,
>> by default, all WRITE statements should be implemented to flush as
>> the last operation before control is returned to the user (on those
>> systems that require explicit flushes).
> Sorry, that can't be done due to legacy codes
Neither can some standard conforming form of FLUSH. And if the
code can be recompiled, the new rule can be applied. If the code
has an old form of FLUSH, it will have to be changed anyway.
> [...] ---one cannot change this now, or
> a lot of codes will plumet in efficiency. [...]
Probably not correct ones. They would have to already have explicit
FLUSHes is nearly all places I'm proposing. If not, they *will* fail
under some circumstances. The *programmer* cannot determine, at the
time the code is written, whether a unit is connected to a shared file
or another process through a pipe, or what. Those things can be changed
by the end-user of the program at the time it is run. So, *all* files
have to be assumed, by the author of the code, as potentially shared.
So, the author of the code must already have put in flushes as I've
suggested. If not, the code is potentially wrong - in a particularly
hard to find, hard to cirrect way.
Now, a well designed system corrects this problem by having the
system recognize situations where FLUSH is required, and not expecting
the author of applications to preciently divine where to put them. Once
they do that, the explicit FLUSH statements will be no-ops anyway
(there being no system call to cause a buffer flush on the systems that
are designed that way).
--
J. Giles
|