6.2 Parameter semantics

The current release is restricted in the sense that only instances of remoteable may be accessed remotely. This has implications for the parameter semantics of reference parameters if the referred objects are not remoteables. The parameter semantics when executing entry's of remote objects are described below.

Before an entry in a remoteable is executed, it is first checked whether the enclosing remoteable is a proxy or not. If it is not, the do part of the entry is executed as in any ordinary object invocation:

entry: (# do (if isProxy then <<SLOT remoteableCallremote:descriptor>> else INNER if); #)

If the remoteable is a proxy, a copy of the transitive closure ^[12] of the entry to be executed is created on the receiver side before the receiver side copy of the entry is executed. After execution, the transitive closure of the entry is sent back and corresponding objects updated. If the transitive closure of the entry object contains remoteable instances, these are not copied, but instead a proxy is created on the receiver side.

Below a formal description of the parameter semantics concerning non-remoteables in the transitive closure of the entry is given. Note that the parameter semantics of remoteables in the transitive closure are exactly as ordinary reference parameter semantics. The semantics of other types of reference parameters are a consequence of trying to support all kinds of parameters despite the current restrictions, and are shown here to give an understanding of why, in most cases, it is possible to use any kind of parameters as usual, and why it may result in unexpected behaviour in some cases if not used with caution. The semantics are thus a compromise between on one side supporting all kinds of parameters and on the other side preserving usual BETA parameter semantics also in the distributed case.

Now, denote by trans(e,s,t) the set of objects reachable through object references from the entry e in the shell s at time t. The set trans(e,s,t) is built by doing a traversal of the object graph rooted in e, and following all references that do not reference a remoteable instance, the BETAENV object or the singular ShellEnv object.

Let state(o,t) denote the state of the object o at time t. Furthermore, define the relation (read is the cause of) by

The parameter semantics operates with four sets of objects. Below e denotes the entry object about to be executed at the sender side. Note that object state as denoted by state only changes during execution of the entry e'.

A: The transitive closure of e immediately after assignment of the enter parameters:

B: The receiver side copy of the set A before the receiver side copy of the entry e, e', is executed.

C: The transitive closure of e' at the receiver side after it has been executed:

D: The transitive closure of e at the sender side after execution:

Now, the parameter semantics are described by the following FOPL formulas:

1. The set B contains copies of all objects in the set A:

2. The set D contains copies of all objects in C. Objects in D are either members of A (as is the entry e), or they are copies of objects in C that are not in B. ( is exclusive or.)

The semantics described above have at least the following implications:

• Reference parameters referring to non-remoteables have approximately Ada-like in/out semantics. The object referred is copied before execution of the entry, and, assuming that it is still in the transitive closure of the entry, updated from the copy after execution.

• If wanted, the parameter mechanism may be used to transfer deep copies of any kind of object between different shells. The notion of deep object copying may be useful, but is orthogonal to distribution. In future versions of BETA distribution, the parameter semantics described above will hopefully be obsolete by removing the restriction that only remoteable instances may be accessed remotely. Instead direct support for object copying may be provided, but not as part of the distribution library. Instead future versions of distribution will support the notion of object movement between different shells.

Serialization limits

• The serialization traversal stops when a remoteable, the BETAENV object or the shellEnv object is met.