Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!ucbcad!ucbvax!VIOLET.BERKELEY.EDU!minshall
From: minshall@VIOLET.BERKELEY.EDU
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: standard interface
Message-ID: <8711110620.AA24292@violet.berkeley.edu>
Date: Wed, 11-Nov-87 01:20:24 EST
Article-I.D.: violet.8711110620.AA24292
Posted: Wed Nov 11 01:20:24 1987
Date-Received: Sat, 14-Nov-87 01:56:17 EST
References: <11631@orchid.waterloo.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 46

No, I don't have any performance figures.

However, I've programmed the UB board both "directly" and via their
socket library.  The "direct" method certainly optimized *PC* processing
cycles.

The standard Unix-style mechanism for performing I/O (and I'm much of
a Unix bigot) is to say "do this", and not get control back until "this"
is done.  On a write, this means you don't get control back until your
output buffer has been stashed away somewhere.  On a read, this means you
don't get control pack until your buffer has been filled up.

This is really non-optimal.  Double-bufferring is a fairly old concept,
and fairly powerful.  Allowing the user to say "start up this I/O, and
let me know when it is complete" is a good performance boost.  It is
not only useful for saving copies (though I don't think one should knock
the performance gains there), but also because it (can) allow one to
get out of the style of "give me data; process data; output data".

One of the benefits of the MIT "upcall" mechanism is that the program
is driven by the data, rather than the other way around (note that I'm
not all that sure that the "upcall" mechanism is the greatest mode of
operation; however, I'd like to provide an underlying mechanism on top
of which "everything" could be built).

(There *is* some philosophy here; I am prepared to neither
defend nor make it more concrete at this time.  I have been spending
a lot of time, though, in the past six months or so wondering how to
move data around inside a machine much faster than we currently do.)

TOTALLY separate topic.  In a message recently, someone mentioned that
select(2) was neat, and (paraphrasing) you could hardly build telnet
without it.  This is very true under Unix; however, I certainly hope
that we are convinced that we are trying to do *networking*, and not
Unix-emulation.  In other words, the mechanisms we want to provide
would work for networking connections, but NOT for the terminal (which
is a large part of what makes select(2) so useful for telnet - it works
for the network AND the terminal).  Most PC applications that need to
check the terminal will use select(2) in "poll" mode, and use
kbhit() (or whatever) to talk with the keyboard.

(I, by the way, at one time wrote my own socket-emulation library, and
included emulation of TTY ioctls and select.  I believe that to have been
a VERY wrong thing to have done (and hereby repent).)

Greg