Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!sdcsvax!ucbvax!TOPAZ.RUTGERS.EDU!hedrick
From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Streams TCP/IP
Message-ID: <8708030237.AA12981@topaz.rutgers.edu>
Date: Sun, 2-Aug-87 22:37:31 EDT
Article-I.D.: topaz.8708030237.AA12981
Posted: Sun Aug  2 22:37:31 1987
Date-Received: Mon, 3-Aug-87 03:48:46 EDT
References: <8707311109.AA17318@RUTGERS.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 14

Does it bother anyone else that streams doesn't seem to make
provisions for multi-processor implementations?  With BSD, you can
hack the kernel all you like to allow for multiple processors.  As
long as your sockets behave the same to the user, he doesn't care.
But with streams, users are supposed to be able to write portable code
to do protocols.  Clearly that level of code is going to need to do
synchronization on multi-processor machines.  As far as I can tell,
the only reason multi-processor implementations are going to be able
to pass the validation tests is because the validation tests don't do
anything non-trivial.  If they included something like a portable
TCP/IP, then it would not be possible to run them unmodified on a
multi-processor system.  Since most non-workstation Unix systems these
days are multi-processor, this is of some practical concern.  What
are implementors doing about this?