🚀 go-pugleaf

In article <2485@shuksan.boeing.com>, sam2747@shuksan.boeing.com (Scott Moody) writes:
|> It seems RPC has been branded as a total co-routine concept,
|> where you totally block until the callee is finished
|> servicing the request, then that callee (server) waits for more.
|> 
|> There is a reason for waiting, and that is because of the return 
|> parameters. A 'connection' is required in some communication
|> schemes. Clicking a button, and not having something happen
|> (even if you wait awhile), is usually better than clicking 6 buttons
|> and then sometime later seeing 6 things happen.
|> 
|> I think the RPC mechanism should be thought of as the Ada rendevous,
|> where one blocks until finished retrieving important information.
|> If there is nothing to return, then let the caller continue.
|> [..deleted..]

One reason for blocking the caller is flow control. This is to
avoid the complexity of coping with the callee being flooded by
repeated calls from the same caller.

However, since the callee has to cope with concurrent callers, I think
having non-blocking calls is just an extension.

The most important reason for blocking the caller is to simplify 
failure semantics. If the caller makes a call and carries on assuming
that the effect of its call is in place while the callee, say, has crashed
in the middle of executing the call, you can get into 'interesting'
situations.

I would rather have blocking procedure/function and non-blocking
send/send-with-reply as two completely separate classes of facilities.
The former being simple but potentially slow; and vice-versa for the
latter.



Parham Momtahan.  
________________________________________________________________________
Bell-Northern Research Ltd, Dept 0R00 |     
PO Box 3511, Station C, Ottawa        |   email: momtahan@bnr.ca 
Ontario K1Y4H7, Canada.               |                                 
------------------------------------------------------------------------ 
X.DISCLAIMER: Contents (if found) may not represent my employer's views.