🚀 go-pugleaf

In article <JAD.92Oct26124437@pimlico.nsa.hp.com> jad@nsa.hp.com (John Dilley) writes:

> 	However, when using an asynchronous paradigm either you have to
> handle the sequencing of multiple incoming replies yourself, or have an
> underlying environment that handles this for you.  It is not obvious to
> me that RPC+threads is therefore inconvenient and inefficient when
> compared with using an asynchronous paradigm.  The effort required to
> receive and dispatch replies in CMIP, an asynchronous network management
> protocol, is nontrivial.  I hope you won't argue that CMIP is more
> convenient or efficient than RPC+threads simply because it uses the
> "common" asynchronous paradigm.

I think that to have a convenient system that supports asynchrony, you
need to have language support.  Sequential languages aren't set up for
it.  If you don't have language support, I agree: asynchrony is
somewhat messy.

For an example of what can be done with language support, see 

@Article{SRoverview,
  AUTHOR = 	"Gregory R. Andrews and Ronald A. Olsson and Michael
		 Coffin and Irving Elshoff and Kelvin Nilsen and Titus
		 Purdin and Gregg Townsend",
  TITLE = 	"An Overview of the {SR} Language and Implementation",
  JOURNAL = 	toplas,
  YEAR = 	"1988",
  VOLUME = 	"10",
  NUMBER = 	"1",
  PAGES = 	"51-86",
  MONTH = 	jan,
  NOTE = 	"An SR compiler is available by ftp from cs.arizona.edu"
}

For example, in SR you can do the following:

        co x := foo(args) ->
           post-prcessing-block
        // y := bar(args) ->                
           another-block
        ...
        oc

The effect is that all the invocations (foo, bar, etc.)  are made
(asynchronously); then the process that's executing the co waits for
replies.  As each reply comes back, the results (if any) are assigned
to the target variables (x, y, etc.)  and then the post-processing
block for that invocation is executed.  When all replies have come
back (or when an EXIT statement is executed in some post-processing
block) execution resumes after the CO statement.  This seems to be
roughly what you are asking for above (and below).

> 	The point of threads is not to simulate asynchronous invocation.
> The point is to preserve the more convenient synchronous model.  I argue
> that the asynchronous model splits the synchronous model up: you make a
> call, [block awaiting responses, select the response to your call,] and
> finally resume.  I'm not an expert with asynchronous calls, however, and
> have some questions.  First, is it possible to make multiple RPCs from
> the same client simultaneously while maintaining their (stack) context?
> In the asynchronous model I'm most familiar with, when you register a
> callback function for you call, make the RPC and return to a dispatcher.
> When your response comes in your callback is invoked to operate on the
> return parameters.  In the mean time you have lost your stack context at
> the point of the RPC.  This can be undesirable, leading to overuse of
> the global space.  The alternative is for your caller to block, but then
> how do you handle multiple simultaneous RPCs?

See above; there is no need for callback functions and stack context
can be made available.

I am not arguing against synchronous communication.  I think that RPC
is a perfectly good primitive---just not the only one.  We aren't
forced to decide between synchronous and asynchronous communication
any more than we are forced to decide between WHILE loops and FOR
loops.  They are both convenient, and they should both be available.

-mike

Michael Coffin				mhcoffin@tolstoy.waterloo.edu
Dept. of Computer Science		office: (519) 888-4820
University of Waterloo			home:   (519) 884-6877
Waterloo, Ontario, Canada N2L 3G1