Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utcsrgv.UUCP Path: utzoo!utcsrgv!perelgut From: perelgut@utcsrgv.UUCP (Stephen Perelgut) Newsgroups: net.unix-wizards Subject: Remote Procedure Calling and Concurrent Euclid Message-ID: <4522@utcsrgv.UUCP> Date: Mon, 11-Jun-84 22:02:17 EDT Article-I.D.: utcsrgv.4522 Posted: Mon Jun 11 22:02:17 1984 Date-Received: Mon, 11-Jun-84 22:26:35 EDT Organization: CSRG, University of Toronto Lines: 35Remote Procedures and Concurrent Euclid I have seen Wichman's note on using remote procedure calls in Concurrent Euclid. It is true that CE is ideal for using remote procedure calls, notably in terms of remote modules and remote monitors. The reason this works out so well is that CE guarantees that VAR parameters can be safely implemented as EITHER call-by-reference OR by value-result. This is only possible because CE prevents aliasing of names, and hence call-by-reference is equivalent to call by value-result. To actually support these remote calls, one would (1) tell the compiler to use value-result instead of reference for remote calls (only). (2) build a little support package to bundle up these parameters to send them to/from the remote site. (3) eventually: add to the language the OUTPUT parameter vs INPUT parameter modifiers to avoid extra copying of parameters that only go one way. The result would be transparent semantics, ie, a program that runs partly remotely would be guaranteed to have the same meaning when it is run completely locally... and when run locally, it would suffer exactly zero runtime overhead. R.C. Holt -- Stephen Perelgut Computer Systems Research Group University of Toronto Usenet: {linus, ihnp4, allegra, decvax, floyd}!utcsrgv!perelgut CSNET: perelgut@Toronto