home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 134 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From std-unix-request@uunet.uu.net  Wed Sep 26 17:30:54 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA20052; Wed, 26 Sep 90 17:30:54 -0400
  4. Posted-Date: 26 Sep 90 18:52:59 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: <546@usenix.ORG>
  10. References: <539@usenix.ORG> <541@usenix.ORG> <543@usenix.ORG> <544@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: U of Toronto Zoology
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 26 Sep 90 18:52:59 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 <544@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  21. >> Programs that want to do two things at once should use explicit parallelism,
  22. >> e.g. some sort of threads facility.  In every case I've seen, this yielded
  23. >> vastly superior code, with clearer structure and better error handling.
  24. >
  25. >I agree that programs that want to do two things at once should use
  26. >threads. However, a program that sends out several connection requests
  27. >is *not*, in fact, doing several things at once...
  28.  
  29. I'm afraid I don't understand:  a program that is trying, simultaneously,
  30. to open several different connections is somehow not doing several things
  31. at once?  I think this is a confusion of implementation with specification.
  32.  
  33. The program *is* doing several things at once, to wit opening several
  34. connections at once.  If "open" is split into several steps, you can
  35. implement this in a single-threaded program, crudely, by interleaving
  36. the steps of the different opens.  My point is that the code is cleaner,
  37. and often details like good error handling are easier, if you admit that
  38. there is parallel activity here and use explicitly parallel constructs.
  39. Then an "open" that is ready for step 2 does not need to wait for all
  40. the others to finish step 1 first.  And if you do this, there is no need
  41. to decompose "open" at all, because each thread just does all the steps
  42. of one open in sequence.  Furthermore, it can then proceed to do other
  43. useful setup chores, e.g. initial dialog on its connection, without
  44. waiting for the others.  This is a far more natural model of what's
  45. going on than forcing everything into one sequential process, and a
  46. much better match for the semantics of the problem.
  47. -- 
  48. TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
  49. OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry
  50.  
  51. Volume-Number: Volume 21, Number 134
  52.  
  53.