Peter Dimov wrote:
Jeff Garland wrote:
Peter Dimov wrote:
Jeff Garland wrote:
But you've already fallen into the trap. Just because the computers are next to each other doesn't mean you are going to get an immediate answer. For example, one of the computers you are communicating with might be really busy doing something (swapping perhaps if it's overloaded). The same can (and does) happen with local calls if the computer is really busy or starts paging. Right, but the programmer has no way of reasonably detecting and handling that condition from within his program. If it's on a remote machine he can and should because it's a frequent issue with networked programs.
Right, that was kind of my point. It's not a black and white issue, but rather a question of frequency or probability. If you can tolerate the slim chances of blocking, you can go with synchronous calls. The fact that it's a different machine doesn't increase the chances that much; interprocess calls to the same machine have a similar chance of blocking, except that you now need half the load, all else being equal. Async is better but requires more coding investment that may not be worth it, pragmatically speaking.
From my own experience (I have my own RMI/RPC framework), I can say that I agree with Peter. I have both sync and async calls and both are beneficial. It is usually a matter of context which one you use. For example I use sync calls during the connection process since in that context nothing else makes much sense. Almost everywhere else I use async calls. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo