Article View: comp.std.unix
Article #580Re: Standards Update, IEEE 1003.4: Real-time Extensions
From: Doug Gwyn
Date: Fri, 28 Sep 1990 16:06
Date: Fri, 28 Sep 1990 16:06
19 lines
1566 bytes
1566 bytes
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In the filesystem abstraction, you open a filename in one stage. You
>can't do anything between initiating the open and finding out whether or
>not it succeeds. This just doesn't match reality, and it places a huge
>restriction on programs that want to do something else while they
>communicate.
UNIX was designed explicitly on the model of communicating sequential
processes. Each process acts as though it executes in a single thread,
blocking when it accesses a resource that is not immediately ready.
While it would be easy to argue that there is a need for improved IPC,
I haven't heard any convincing arguments for making asynchronity
explcitly visible to a process. In fact, it was considered quite a
step forward in computing back in the old days ("THE" operating system,
for example) when viable means of hiding asynchronity were developed.
Volume-Number: Volume 21, Number 144
Technical Details
Message-ID:
<556@usenix.ORG>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!usenix!jsqReferences:
<523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!usenix!jsq From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.std.unix Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <556@usenix.ORG> Date: 28 Sep 90 16:06:42 GMT References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG> Sender: jsq@usenix.ORG Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 19 Approved: jsq@usenix.org (Moderator, John Quarterman) X-Submissions: std-unix@uunet.uu.net