home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 163 / text0000.txt < prev   
Encoding:
Text File  |  1990-12-05  |  2.6 KB  |  61 lines

  1. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  2.  
  3. In article <547@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  4. >> The program *is* doing several things at once, to wit opening several
  5. >> connections at once.
  6. >
  7. >``Opening a connection'' is really an abuse of the language, because a
  8. >network open consists of at least two steps that may come arbitrarily
  9. >far apart...
  10.  
  11. This is the nub of the issue, and it's a difference in semantic models.
  12. Dan insists on seeing open as a sequence of operations visible to the
  13. user, in which case his viewpoint is reasonable.  I prefer the Unix
  14. approach -- the details of an open are none of the user's business,
  15. only whether it succeeds or fails -- in which case "opening a connection"
  16. is entirely reasonable terminology, and opening several at once (i.e.
  17. sending out multiple requests before receiving acknowledgements) is
  18. indeed doing several things at once, best handled with explicit
  19. parallelism.
  20.  
  21. Both models are defensible, but I would sort of hope that in a Unix
  22. standard, the Unix model would be employed.
  23.  
  24. It is easy to construct examples where explicit parallelism buys you
  25. things that the multi-step model can't easily achieve, such as writing
  26. data from one connection to disk while another one is still exchanging
  27. startup dialog.  One *can* always do this in the multi-step model, but
  28. it amounts to simulating parallel threads.  The main structure of the
  29. program turns into:
  30.  
  31.     for (;;) {
  32.         wait for something to happen on some connection
  33.         deal with it, in such a way that you never block
  34.     }
  35.  
  36. which does work, but greatly obscures the structure of what's going on,
  37. and tends to require all sorts of strange convolutions in "deal with it"
  38. because of the requirement that it not block.  (If it blocks, activity
  39. on *all* connections blocks with it.)  BSDish server code tends to be
  40. very hard to understand because of exactly this structure.  With multiple
  41. threads, each one can block whenever convenient, and the others still
  42. make progress.  Best of all, the individual threads' code looks like a
  43. standard Unix program:
  44.  
  45.     open connection
  46.     do reads and writes on it and other things as necessary
  47.     close it
  48.     exit
  49.  
  50. instead of being interwoven into a single master loop with all the rest.
  51.  
  52. Almost any program employing select() would be better off using real
  53. parallelism instead, assuming that costs are similar.  (It is easy to
  54. make costs so high that parallelism isn't practical.)
  55. -- 
  56. Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
  57. operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry
  58.  
  59. Volume-Number: Volume 21, Number 163
  60.  
  61.