Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!decwrl!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Streams TCP/IP
Message-ID: <25133@sun.uucp>
Date: Fri, 7-Aug-87 16:10:52 EDT
Article-I.D.: sun.25133
Posted: Fri Aug  7 16:10:52 1987
Date-Received: Sun, 9-Aug-87 08:47:56 EDT
References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <4609@felix.UUCP>
Sender: news@sun.uucp
Lines: 38
Xref: mnetor comp.dcom.lans:719 comp.protocols.tcp-ip:856

> We are considering using streams as a basis for some future work on
> our distributed file system, as well as for networking.  The problem
> Guy cites above, inability to block on resources, seems to be a
> MAJOR one.

Nope.  AT&T's RFS uses STREAMS to talk to the transport layer it
uses, so there is an existence proof.

The secret is that the AT&T RFS (or NFS, or probably Todd Brunhoff's
RFS) server is implemented as a separate UNIX process; the server
code runs in the context of that process (or processes, if you have
more than one server).  *That* process can block waiting for a disk,
or other resource, if it wants to.

The client code probably also runs in the context of a UNIX process;
if it's running in the process that makes the request, it obviously
is, and NFS has a daemon to handle asynchronous requests.  This code
can also block if it has to.

The trick here is that none of the file system code is implemented as
a STREAMS module; that's not really what STREAMS were developed for.
However, there may be cases where something that STREAMS *was*
developed for, such as a network protocol implementation, would want
to block.  There are cases, both in the STREAMS framework and the
4BSD sockets/protocols framework, where it can't do this
conveniently.

The problem with the STREAMS mechanism is that there are *no* places
where you can *guarantee* that you can block, if you want to follow
the letter of the law.  If you "know" that there are no modules with
service procedures above you, and you "know" the way put procedures
are called, so that you "know" that your module's "put" procedure
will be called in the context of the process making the request that
causes the message to be sent downstream, you could cheat; however,
you can't really "know" any of those things.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com