[clean-list] UNIX (or POSIX) I/O

Donn Cave donn@u.washington.edu
Fri, 21 May 2004 11:21:38 -0700


On Friday, May 21, 2004, at 08:34 AM, Maks Verver wrote:
...
> Regarding the implementation of POSIX-compliant low-level I/O 
> operations: it
> shouldn't be that hard to wrap them, but you'd probably end up with 
> similar
> functions as already provided by the StdFile module (except that your
> functions would operate on an even lower level). Personally I'd prefer 
> if
> someone would fix the StdFile module instead. If it would work 
> correctly, I
> wouldn't want to use the low-level I/O operations instead (just as I 
> don't
> use them from C, except for special/non-file descriptors).

Yes, they really are most useful when you're dealing with a file that
is (or may be) a pipe, socket, tty or some other "slow" device where
you're dealing more directly with the source events.  In this case,
buffered I/O as provided by for example the C stdio library can be
a problem.  If for example you want to dispatch on input events from
several such devices, already buffered input is a complication -
from the system's point of view it has already been read from the
device, but from the program's point of view it has yet to be read
from the file.  Then there are miscellaneous low level functions you
may need, like exotic open parameters, or redirection functions like 
dup2.

A lot of this is in some sense platform dependent.  Some of it may be
meaningful on Windows, some likely not, and at best it may be kind of
an eccentric preoccupation there.  Elsewhere, though, while programs
don't by any means always use these functions, they are pretty 
important.

Then, as I mentioned, I would want to write a buffered I/O Clean 
library -
say PosixFile - that really does largely overlap the functionality of
StdFile.  For the present, that would resolve my problem with StdFile,
because of course PosixFile would really support the UNIX file 
descriptor
abstraction even though it's a layer on top of that.  That might be a
temporary expedient, depending on how StdFile develops, but I actually
have not yet seen a buffered I/O library that works well in the context
I alluded to above - C stdio doesn't - so it might retain some 
usefulness.

Of course the real problem is, I didn't even have time to write this
letter, let alone do all these things!

	Donn Cave, donn@u.washington.edu