Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!usenix!jsq
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <543@usenix.ORG>
Date: 25 Sep 90 16:44:28 GMT
References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
Sender: jsq@usenix.ORG
Organization: U of Toronto Zoology
Lines: 17
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

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.

Programs that want to do two things at once should use explicit parallelism,
e.g. some sort of threads facility.  In every case I've seen, this yielded
vastly superior code, with clearer structure and better error handling.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry

Volume-Number: Volume 21, Number 131