Path: utzoo!mnetor!uunet!husc6!ncar!noao!arizona!lm
From: lm@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4441@megaron.arizona.edu>
Date: 22 Mar 88 19:02:34 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> <20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA>
Reply-To: lm@megaron.arizona.edu.UUCP (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 24

In article <7511@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Unfortunately, the implementation you probably have in mind is
>tightly coupled to sockets.  Wollongong developed a STREAMS-based
>TCP/IP for AT&T; I don't know how good it is but there is no a
>priori reason that a STREAMS implementation couldn't be as good as
>one based on sockets.

It is my personal belief that streams was intended as a _slow_ terminal
"virtualization" (Padlipsky would be proud) mechanism.  As such, one 
should probably think carefully about the performance aspects of 
implementing high bandwidth drivers that use streams.  One could (I have
seen it) suggest that all drivers talk through streams interfaces.  Seems
like a nice idea (modularity being the buzzword that comes to mind) until
you start counting how many times you say "bcopy(src, dest, len)".  This
might be a moot point when we have infinitely fast CPU's and memories :-)

(It should be obvious but I'll drive it home:  the streams code that I've
seen copies the data out of the upper level buffer and then into the 
lower level buffer [assuming "downward" movement].  The copying dominates
the time spent in the streams drivers.  If streams can handle imbedded 
pointers in their data then my comments are meaningless.)
-- 

Larry McVoy	lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm