🚀 go-pugleaf

John Dilley <jad@nsa.hp.com> writes:
> 	The point is to preserve the more convenient synchronous
> 	model.
 
In article <5426@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) wrote:
> But is it really more convienient?  I think it's rather contrived.  I
> believe that we live in an asynchronous world.  As such, asynchronous
> programming is "natural" to me.

Just a trivial point: the fact that we live in an asynchronous world
doesn't mean that we've learned how to manage asynchrony.  We live in
a massively parallel world too, but I don't think many would claim we
can manage massive parallelism yet.  For at least some applications,
the smaller complexity of synchronous programming may be necessary to
create a reliable solution to the problem.

warkent@ltisun14.epfl.ch (Ken Warkentyne) writes:

>Have you tried writing something in CCS or CSP, which are based
>on synchronous communications?  It seems quite natural to me.
>I suggest that people interested in the suitability of
>synchronous concurrent programming read Robin Milner's book on CCS.

If I understand both of you correctly, one of you misunderstands the
other :-)  When Mr. Hayes and Mr. Dilly say "synchronous", they mean
"the client sends a message to the server and then blocks until the
server sends a reply".  When they say "asynchronous" they mean that
the client need not wait.  Both of these alternatives are usually
"asynchronous" in the CCS/CSP sense, because the message transmission
by the client and the message receipt by the server are not the same
event.  I think modeling client/server "synchrony" and "asynchrony"
in CCS or CSP would involve modeling the communication media as a
separate process, which would lose you a lot of the benefits of CCS and
CSP's "synchronous" communication.

Or perhaps I misunderstand everybody, in which case, never mind :-)