home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / v21 / 131 < prev    next >
Internet Message Format  |  1990-12-05  |  2KB
  1. From std-unix-request@uunet.uu.net  Tue Sep 25 16:34:14 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA16616; Tue, 25 Sep 90 16:34:14 -0400
  4. Posted-Date: 25 Sep 90 16:44:28 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: henry@zoo.toronto.edu (Henry Spencer)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <543@usenix.ORG>
  10. References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: U of Toronto Zoology
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 25 Sep 90 16:44:28 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  19.  
  20. In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  21. >In the filesystem abstraction, you open a filename in one stage. You
  22. >can't do anything between initiating the open and finding out whether or
  23. >not it succeeds. This just doesn't match reality, and it places a huge
  24. >restriction on programs that want to do something else while they
  25. >communicate.
  26.  
  27. Programs that want to do two things at once should use explicit parallelism,
  28. e.g. some sort of threads facility.  In every case I've seen, this yielded
  29. vastly superior code, with clearer structure and better error handling.
  30. -- 
  31. TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
  32. OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry
  33.  
  34. Volume-Number: Volume 21, Number 131
  35.  
  36.