🚀 go-pugleaf

From:  henry@zoo.toronto.edu (Henry Spencer)

>From:  Jason Zions <jason@cnd.hp.com>
>How about because it constrains implementations to make DNI
>kernel-resident?

Nonsense.  Nothing in 1003.n constrains implementations to make anything
kernel-resident.  Things like read() are functions, which may or may not
reflect the primitives of the underlying kernel.  They are merely required
to communicate -- somehow -- with something that performs the required
services.

Why have two different kinds of endpoints for I/O?  We already have one
which is general enough to encompass almost every kind of I/O under the sun.

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented. What does it mean to seek() on a network endpoint?

Read()/write() are stream operations that work perfectly well as record
operations too.  As witness Unix ttys, which are record-oriented devices
on input, and Unix magtapes, which are record-oriented both ways.  As for
what it means to seek on a network endpoint, exactly the same as it means
to seek on a tty:  probably nothing.  But why invent new mechanisms for 
I/O when the old ones will do perfectly well?

"Don't fix it if it ain't broken."

                                         Henry Spencer at U of Toronto Zoology
                                          henry@zoo.toronto.edu   utzoo!henry

Volume-Number: Volume 20, Number 93