🚀 go-pugleaf

In article <7201@transfer.stratus.com>, cme@ellisun.sw.stratus.com (Carl Ellison) writes:
|> The bad point is that while the callee is doing its thing *and* while that
|> call is being transmitted *and* while the reply is coming back, the caller
|> is twiddling its thumbs -- either literally spinning or doing a task
|> switch.  As processors get faster, the time for the callee to do its thing
|> goes down -- but the communication time doesn't (since the speed of light
|> doesn't change).  So the number of instructions wasted in the caller goes
|> up, if the caller spins.  This forces the caller to task-switch or waste
|> time.


RPC's can be both synchronous and asynchronous, If you can use asynchronous RPC's,
then the initiating process can go on processing. And in todays world, a machine
that is waiting on an RPC for one process will probably go out an work on another
process, which tends to keep the overal user response time faster, since some of
the work is being done somewhere else.

And in response to the original poster...rpc's _have_ been around for a while. 
If you have ever used NFS, you have used RPC's, since this is how NFS obtains
files from the NFS server.


-- 
Jon Alperin - Bellcore
---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674

* All opinions and stupid questions are my own *

"I don't have any experience running up a 4 trillion dollar debt" - Ross Perot
"If there's a fair way, I'm all ears" - Ross Perot