Many message systems have a primitive mailbox construct where messages conceptually reside after being sent and before being received. We considered this design in Keykos but decided to gain the conceptual and implementation economy in putting these two functions into the same Keykos construct—the domain. When a message is sent across a trust boundary to be interpreted by user mode code, the sender determines the message recipient by selecting a start key that the sender holds. The start key designates a domain, not a mailbox.

While a mailbox design need not really cause each message to be copied twice, it seemed that such an optimization would itself have a real cost. Also Keykos holds to rule of no stuck (unswappable) resources and no unaccountable space. It was unclear how to do this with mailboxes. For those cases where the mailbox seems logically necessary a real domain can limit itself to doing just the desired mailbox function. Mailboxes fell to Occam’s razor.

We thus conflate the domain and mailbox. This decision requires a dispatcher for some applications.

There are a variety of mailbox designs, whether or not they are primitive. If the mailbox is primitive what action does the server take when it has finished a task and is ready for another? Indeed is there a concept of a sub-server processing sequential requests, or perhaps a new server is created for each request. The same mechanism can be described in these two ways depending on the abstraction levels. In one scheme the server implicitly asks for a new message as it replies to the previous message. This is so of the Keykos domain. When a new server is created, by contrast, it must have a pristine state and since real hardware is not created upon these events, some mechanism, somewhere, has reallocated hardware and configured it to become the new server. There remains the question of who is responsible for putting that hardware into a known state. When a square-root routine is called this mechanism is the incrementation of the stack pointer and the routine code is trusted not to examine what was there before.

In the Keykos design there is exactly on system call: Invoke a key.