Path: utzoo!attcan!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!jsq
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <13195@cs.utexas.edu>
Date: 3 Oct 90 20:49:11 GMT
References: <529@usenix.ORG> <548@usenix.ORG> <106697@uunet.UU.NET>
Sender: jsq@cs.utexas.edu
Organization: IR
Lines: 55
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)

In article <106697@uunet.UU.NET> peter@ficc.ferranti.com (Peter da Silva) writes:
  [ Programs depend on write() working. ]

On the contrary. When the descriptor is unreliable, you get an I/O
error or the data is simply corrupted; this is exactly what happens with
disk I/O. Programs that handle errors on read() and write() are more
robust than programs that don't.

More commonly, when the descriptor is dynamic and the other side drops,
you get a broken pipe. This is certainly not a rare failure mode.

In context, I said that open() is only appropriate for reliable, static,
local I/O objects. You seem to be arguing that read() and write(), and
file descriptors in general, also require reliable, static, local I/O
objects, and so my distinction is silly. But UDP sockets, pipes, and TCP
sockets are unreliable, dynamic, and remote file descriptors
respectively, and read()/write() work with them perfectly.

> > You can read() or
> > write() reasonable I/O objects through file descriptors. Very few
> > programs---the shell is a counterexample---need to worry about what it
> > takes to set up those file descriptors.
> And that's the problem, because the shell is the program that is used to
> create more file descriptors than just about anything else. If the shell
> had a syntax for creating sockets and network connections we wouldn't be
> having this discussion...

Oh? Really? I have a syntax for creating sockets and network connections
from my shell. For example, I just checked an address by typing

  $ ctcp uunet.uu.net smtp sh -c 'echo expn rsalz>&7;echo quit>&7;cat<&6'

So we shouldn't be having this discussion, right?

> but then if it did then you might as well make
> it be via filenames...

Why? I don't see a natural filename syntax for TCP connections, so why
should I try to figure one out? What purpose would it serve? Only two
programs---a generic client and a generic server---have to understand
the filenames. If those two programs work, what's the problem?

  [ shm and sem are reliable, static, local ]

As a BSD addict I don't have much experience with those features, but I
believe you're right. So feel free to put shared memory objects into the
filesystem; I won't argue. Semaphores, I'm not sure about, because it's
unclear what a file descriptor pointing to a semaphore should mean. Are
semaphores I/O objects in the first place?

---Dan

Volume-Number: Volume 21, Number 182