Path: utzoo!attcan!uunet!usenix!jsq
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <566@usenix.ORG>
Date: 1 Oct 90 14:59:12 GMT
References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG> <547@usenix.ORG>
Sender: jsq@usenix.ORG
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 26
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: peter@ficc.ferranti.com (Peter da Silva)

In article <547@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> ``Opening a connection'' is such a common phrase that we automatically
> accept it as a description of reality, and consequently believe that it
> is well described by open(); but it isn't. The time between request and
> acknowledgment is filled with nothing but a void.

There are a *number* of cases in UNIX where an open() does not return in
a determinable time. The correct solution to this is not to pull stuff out
of the file system, but to provide an asynchronous open() call (that can
well be hidden by a threads library, but the mechanism should be there).

This is related to the issue of whether network end-points belong in the
file system, but it is not the same issue because there's much more than
networks involved... including objects (serial ports with modem control,
in particular) that are already in the filesystem.

Oddly enough, the latest draft of P1003.4 that I have available does NOT
include an asynchronous OPEN request. This is a serious omission.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

Volume-Number: Volume 21, Number 158