home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0134.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  1.9 KB  |  36 lines
  1. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  2.  
  3. In article <544@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  4. >> Programs that want to do two things at once should use explicit parallelism,
  5. >> e.g. some sort of threads facility.  In every case I've seen, this yielded
  6. >> vastly superior code, with clearer structure and better error handling.
  7. >
  8. >I agree that programs that want to do two things at once should use
  9. >threads. However, a program that sends out several connection requests
  10. >is *not*, in fact, doing several things at once...
  11.  
  12. I'm afraid I don't understand:  a program that is trying, simultaneously,
  13. to open several different connections is somehow not doing several things
  14. at once?  I think this is a confusion of implementation with specification.
  15.  
  16. The program *is* doing several things at once, to wit opening several
  17. connections at once.  If "open" is split into several steps, you can
  18. implement this in a single-threaded program, crudely, by interleaving
  19. the steps of the different opens.  My point is that the code is cleaner,
  20. and often details like good error handling are easier, if you admit that
  21. there is parallel activity here and use explicitly parallel constructs.
  22. Then an "open" that is ready for step 2 does not need to wait for all
  23. the others to finish step 1 first.  And if you do this, there is no need
  24. to decompose "open" at all, because each thread just does all the steps
  25. of one open in sequence.  Furthermore, it can then proceed to do other
  26. useful setup chores, e.g. initial dialog on its connection, without
  27. waiting for the others.  This is a far more natural model of what's
  28. going on than forcing everything into one sequential process, and a
  29. much better match for the semantics of the problem.
  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 134
  35.  
  36.