Inter-process Signaling

Many operating systems provide a primitive way for one process to signal another. Gnosis does not. We anticipate that the gate jump fills this function more directly than the interprocess signal. In particular the examples given to motivate signaling involve processes that cannot change their capabilities, as gates allow. Usually the processing of a single transaction will involve a single process passing sequentially thru a set of "domains" via gates.
The above paragraph is meaningless if one takes the view of "process" referred to in (proc). In that view our gate jump is an interprocess signal.

Interprocess signaling usually involves one process sending a signal to another and going to sleep, waiting for a return signal. If the second process is already running, we unnecessarily cause the first transaction to wait, not on a processor but a process. If the second process is not running then we have something that ends up looking functionally equivalent to a gate jump {but without the opportunity to pass capability parameters}.

Early in the design of computers the interrupt was invented. It was to direct the attention of a processor to a more important task, or at least one that should not wait. Another use was to recover from the execution of a program that appeared to be in an unterminating state.

In Gnosis we interrupt the real processor but we do not interrupt domains. If there is a more important task that may need to run before some other task is finished, give that important task its own domain and it will run without logically involving the primary task.

In some systems a process is "interrupted" by a signal to notify it of a condition that may influence its execution. Usually in such cases the interrupt routine will merely set a bit that is tested by the main program at the points where the alternate processing is appropriate. In Gnosis you should create a domain which waits for the signal and then sets the bit in shared memory and resumes waiting.

In Gnosis there is no primitive object which behaves like a semaphore, but clearly one could be built outside the kernel using a gate. See (p3,mutex) for why we do not provide such a function even outside the kernel.

The Hydra system may vest in a procedure (program) the right to do certain operations on certain types of objects. (See The Hydra Song Book. Department of Computer Science. Carnegie-Mellon University, Sept 29, 1975.) In Hydra there is an open ended set of object types. For the procedure to do the allowed operation on an object it must hold a capability to the object as well as a template for the object type. The template allows "amplification" of the rights of the object capability.

Normally in Gnosis, an object of a particular type holds a pointer to the {only} code that can manipulate its internal structure. (The object is a domain and the pointer is in its memory tree.)

Hydra provides for an open ended set of programs that have access to the internal structure. This effect may be had in Gnosis with a domain creator. A start key to the domain creator plays the role of the template capability. Doing operations on an object requires getting the keys in the domain referred to by the start key. Given a start key to a domain, a domain creator will get those keys if the domain was created by that creator. Start keys created using the domain key represent objects of the given type.

In fact, the domain annexes are unnecessary for this purpose. The closest analogy to Hydra is one in which a capability to a Hydra object is represented by a start key to a domain (i.e. a node) with (possibly) no annexes. Such a domain is malformed but it is not designed to be called. (In this case the names "domain" and "start" are not so appropriate.) The brand of the domain corresponds to the type of the Hydra object. A Hydra template capability is represented by a key to a domain creator with the appropriate brander. A domain with such a key can use it to turn an appropriate start key into a domain key, which allows it to access the keys inside the domain (in the domain root). This corresponds to rights amplification in Hydra. See (one-node) for a better idea.

There are currently no domain creators which create such malformed domains, but if the demand develops they will be provided. Clearly the domain tool {(p2,mkdomk)} allows for that possibility. The advantage of using a malformed domain instead of a regular one is only that it uses one-third the space.

If the object is a segment or meter then operations similar to the above can be done with the object's keeper.

Some capability-based systems provided authority to expend resources in a form analogous to a battery. Such a capability takes the form of an unrescindable supply of resources that can be hidden from everyone but the kernel. These resources can be spent at any time. In contrast, Gnosis supplies resources through its meters in a way that provides for rescindable power. This allows the keeper of a meter to turn on and off some collection of programs that are inferior to the meter. This effect can be had partially with batteries by providing batteries with small charges and inhibiting the battery replacement. This tends to make battery replacement part of the logic of the application program. There can be no assurance that after a period of inhibited battery replacements that there are no more usable batteries. There would seem to be no limit on the hoarding of batteries. Gnosis' meters may be used to control the level of multiprogramming. Since the readings of Gnosis' meters are up to date they can be accurately used to charge more for resources during some parts of the day. With batteries, resource tokens could be hoarded and used when real resources were scarce. See (p3,admeter).

It is widely suspected that capability based systems are weak in that they allow uncontrolled propagation of capabilities.
The most basic counter to this suspicion is that you can't propagate capabilities to those with whom you cannot communicate. When capabilities are mixed with more common access policies it might be true that it is hard to tell where a capability might get to.

Another point is that unlike data, capabilities cannot be passed by word of mouth.

Some writers have suggested that if it were possible to somehow restrict the ability to copy or move capabilities, this problem would be alleviated.

See (psos,) for some fragmentary comments on what I believe the PSOS and Hydra schemes to be.

I argue here that if capabilities were made uncopyable it would merely make such systems less efficient but not more secure.

Suppose that X can call Y and that X holds capability b. If b is copyable (as it is in Gnosis) then X can give b to Y so that Y will hold b in the same sense as X does. If b is not copyable but X is intent on giving to Y the authority embodied by b then X can serve as a go-between and call b according to the instructions of Y, with whom X can communicate. This assumes that X will continue to exist or that X can produce a domain with access to b that will continue to exist.

If one were to try to defeat this collusion by deleting X, two problems remain: what about the time before X is deleted, and what of the general ability to create perpetual programs such as an X' which might continue the proscribed behavior.

If X can't give the capability to the object he creates then how do objects get capabilities?

Another reason not to restrict the copying of capabilities is that we have no experience in writing algorithms in which the computing objects are not copyable.

LOOSE END: discuss Hydra and iPAX ideas here.

A module in the sense of Euclid is a subroutine with several entries and values {of variables} that persist between calls. It is clear how to implement a module with a domain. This requires at least three nodes per module instance. See (one-node) for another idea.