Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!usenix!jsq
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <546@usenix.ORG>
Date: 26 Sep 90 18:52:59 GMT
References: <539@usenix.ORG> <541@usenix.ORG> <543@usenix.ORG> <544@usenix.ORG>
Sender: jsq@usenix.ORG
Organization: U of Toronto Zoology
Lines: 34
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

In article <544@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>> Programs that want to do two things at once should use explicit parallelism,
>> e.g. some sort of threads facility.  In every case I've seen, this yielded
>> vastly superior code, with clearer structure and better error handling.
>
>I agree that programs that want to do two things at once should use
>threads. However, a program that sends out several connection requests
>is *not*, in fact, doing several things at once...

I'm afraid I don't understand:  a program that is trying, simultaneously,
to open several different connections is somehow not doing several things
at once?  I think this is a confusion of implementation with specification.

The program *is* doing several things at once, to wit opening several
connections at once.  If "open" is split into several steps, you can
implement this in a single-threaded program, crudely, by interleaving
the steps of the different opens.  My point is that the code is cleaner,
and often details like good error handling are easier, if you admit that
there is parallel activity here and use explicitly parallel constructs.
Then an "open" that is ready for step 2 does not need to wait for all
the others to finish step 1 first.  And if you do this, there is no need
to decompose "open" at all, because each thread just does all the steps
of one open in sequence.  Furthermore, it can then proceed to do other
useful setup chores, e.g. initial dialog on its connection, without
waiting for the others.  This is a far more natural model of what's
going on than forcing everything into one sequential process, and a
much better match for the semantics of the problem.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry

Volume-Number: Volume 21, Number 134