Article View: comp.std.unix
Article #534Re: Standards Update, IEEE 1003.4: Real-time Extensions
From: Henry Spencer
Date: Tue, 25 Sep 1990 16:44
Date: Tue, 25 Sep 1990 16:44
17 lines
1446 bytes
1446 bytes
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
Technical Details
Message-ID:
<543@usenix.ORG>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!usenix!jsqReferences:
<495@usenix.ORG> <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!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