Let me describe how Keykos works in this area. We did not find any patterns that we could not support. Design decisions such as these determine what patterns are efficient, but hopefully does not exclude patterns.

For instance we unified mailbox and domain. Most other systems separate these two and an actor (domain in our case) asks it there is mail in some mailbox, or waits for there to be some. When your pattern requires asking a mailbox whether there is mail, you can devote a Keykos domain to serve as that mailbox. This is an example of a difference only in performance, and then not a large difference.

Quite literally a domain consists of:

Segments are composed recursively of pages or other segments. Two ‘instances’ (in the C++ sense) will have the method defining code in a subsegment, and the instance variables in another mutable segment. Segments can be equipped with keepers which are programs that run when some currently undefined portion of the segment is touched. The keeper can then define it.

There are three valid domain states:

Some literature calls our ‘available’ state an “open wait” for it it is ready to take on some hew task. The PC of such a domain points to code that will dispatch on an integer parameter that chooses which method for the current call.

That literature uses “closed wait” to describe we call a waiting domain that insists on getting an answer to some question before the subject is changed. In Keykos it may be restarted only by invoking the return cap that was produced when it was called The PC of such a domain points to just after a cap call site.

Note that there is no explicit stack known to the kernel. The distribution of return caps, which the kernel does not consider, is the manifestation of stack.

There are three variants to cap invocation:

Here is a more complete definition of segment.