🚀 go-pugleaf

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.

I have modified the Sun rpc mechanism to provide this 
important capability, which gets close to a threads concept.
This only required a few lines of C code.

I also modified a prototyping language to include a
	CRITIAL_START and CRITIAL_END capability, where one can
copy input parameters, and pass back anything, then both can
go on their way.

Unfortunately the caller still blocks until the server is ready
to read the message -- even if it quickly finishes a rendevous.
If you don't want to block, then provide a queing server that
performs the service of calling the desired server when it
is appropriate, and let you get on.
-- 
Scott Moody   (206) 477-4295   "There are no answers .. just cross references"
     scott@shuksan.boeing.com  
     uunet!bcstec!shuksan!scott