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