Description

For some programs, the precise details of invocation semantics are important. This page provides a detailed description of the invocation semantics.

To invoke a key, a process sets up the message arguments in it's registers and then performs a kernel trap. When this trap occurs, the kernel performs the following steps:

1. Sender is prepared to send.

   1. The sender's data pages, if any, are checked to be sure they are in-core and readable.

   2. The invoked key is validated and converted to a void key if stale.

   NOTE that in order to be sending at all the sender must be well-formed. This implies that it has a key registers node, which we may wish to reconsider.

2. The invoked key is checked to determine the receiver, which may not necessarily be the sender. If invoked key is a gate key, the, receiver must be extracted from the key and loaded into context cache.

3. The recipient is prepared to receive. The recipient may not be well formed.

   1. If recipient has no key registers node, or is otherwise malformed, what happens depends on the invocation type:

      fork, call	sender receives RC=KT+1
      return	sender cannot detect failure

   2. If the recipient does not already have valid data pages where the receive buffer should be located, and is not currently faulted, the following steps occur:

      1. If the recipient's address space keeper is available, it is invoked with the usual address space fault. It is passed a fault key to the recipient process.

      2. The invocation is nullified. The invoker remains in the running state just prior to the invocation, and is stalled on the recipient's address space keeper.

4. By this point, a message structure has been constructed and the key can be invoked.

5. Sent keys and data are logically copied into a holding area. No such holding area exists in the kernel; this statement simply makes it well-defined what happens when key sent keys or data are overwritten by the reply.

6. The key action is performed. In the case of a gate key this is simply a transferral of the thread to the new process.

7. Reply keys are delivered to the recipient.

8. Reply data is delivered to the recipient if delivery would be prompt. If delivery would not be prompt, the message is discarded and the high bit of the recipient's fault code is set to indicate loss of message data. Delivery is non-prompt under the following circumstances:

   • The recipient was faulted at the time of the invocation.

   • The address space keeper declined to provide the backing store for the receive buffer(s).

9. The recipient is set running. If it's fault code is nonzero, it's process keeper will be invoked before the recipient performs any units of operation.

Notes for Shared Services

An issue in the design of shared services is that they must not be delayed by invoking a key that might block. For this reason, the return operation silently discards the reply if the destination capability is not a resume capability. If it is desired to return on a non-resume capability, npreturn should be used instead.