Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!jsq
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <107042@uunet.UU.NET>
Date: 1 Oct 90 20:02:17 GMT
References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG> <547@usenix.ORG>
Sender: jsq@uunet.UU.NET
Organization: U of Toronto Zoology
Lines: 59
Approved: jsq@uunet.uu.net (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

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