{nonref}The {Case of the} Disappearing Components

There are two general ways to recover the resources used in the construction of some object. The object itself may have the logic to destroy itself and recover those resources, or the space bank from which the object was constructed might be be directed to recall the storage. The advantage of the second scheme is that the object need not have the destruction logic.

There is a general problem with the bank however. If the object runs asynchronously with the domain that signals the destruction of the space, the object may be running when the destruction is in progress. As this occurs various nodes and pages from which the object is built will disappear. The logic of the programs in the object can not generally be expected to behave in an anticipated maner in this case.

Note that there is no danger that the object will do something that its capabilities would not have allowed, but merely that those capabilities may be misused by the stricken program to cause deleterious effects on other objects. The object may thus misuse its authority.

One fairly general solution may be for the object to run under a meter that will be off while the space bank reclamation occurs. There could be an official source of such meter-bank pairs. See (p2,mbi).

The trap codes defined at (p1,badmeter) exacerbate the foregoing problems.

This problem arises for factories whose .keeper is a hole which is a VDK (or some such) that leads to the builder.

An {understated} design goal of Gnosis style abstraction with domains is that it be possible, in the important cases, to write your abstraction implementation code so that it won't break unless there is a bug in it.

The requestor, in particular, should be unable to break the code unless there is a bug in it. If the requestor passes a bad meter, the domain breaks with no convenient way to determine whether to blame this event on the requestor or builder.

Before domains trapped on invalid meters, the following scheme was {and still is} suitable for negotiating the blame:

The requestor has a "debug-meter-key" that is a meter key to a valid empty meter with a meter keeper designed to retrieve resume keys and pass them to the holder of the debug-meter-key.

The requestor passes this debug-meter-key to the requestor key and claims the resulting resume key.

This resume key is then passed to the builder thru normal mail mechanisms.

The point is that the builder may be willing to get up at 3 a.m. if HIS DOMAIN broke, whereas he may prefer to wait until 8:30 a.m. to hear evidence that someone else may wish to present that something is wrong.

This is, perhaps, a particular case of a more general problem whereby a meter keeper is supposed to be unable to influence the progress of those processes under its meter except to impede it. This invalid meter traps the meter keeper can do more. This principle is still written down in the manual somewhere.

Another argument in this respect is that invalid meter trapping is not a fundamental debugging function. By this I mean that all of the debugging tools that you needed before you still need. The tools that are necessary to track down a domain that is trying to jump to itself suffice to track down a domain that is trying to run on an invalid meter.

It seems to me {Bill} that there are some confusions in the above. The logic described to get a resume key to the .program works because the meter is valid {although dry}. The way you debug a domain trying to jump to itself is to look at the trap code in its domain keeper. {I remember seeing it a few times!} This can be viewed as the same mechanism with two different "reason" codes to distinguish the situations. The whole reason for the trap is to eliminate one of the causes of a process disappearing without a trace. If you don't want to be awakened at 3 a.m., then put in a .keeper that recognizes the trap code and returns a defined return code to the caller to tell him it's his problem. {The factory could also DISCRIM the "meter" key and cover most of the "cockpit errors".}

Creators typically accept a space bank from their caller. If this space bank were to be equipped with a guard, the components built from the bank might disappear without notice. The creator is liable to have its logic disrupted and fail to become available for subsequent creations.

Creators written so far (1980 Nov) have found it easy to anticipate flaky banks.

The factory (p2,factory) is a general solution to this problem. The domain which is designated by the public keys to the creator never invokes the suspect space bank and cannot be impeded by it.

Some segment keepers cause pages to change from read-write status to either read-only or undefined. There are two general reasons for this:
It is convenient (perhaps necessary) to pass thru such a state while working toward the required state.

An information compressing scheme will set to undefined such pages that it has compressed until a reference to that page indicates that the (uncompressed) value is required.

If an entry block specifies a parameter string in such a page while the page is not read-write a jump using that parameter string will fail.
Note that in the first above example there will be no problem if the domain with the entry block is the same as the domain whose memory reference caused the action of the segment keeper. This is because start keys to the domain can't jump because the domain is busy and the only resume keys are held by the segment keeper.

We originally installed the CMS editor in the simplest way we knew. The result was that there was one editor instance. If I called the editor while you were using it I had to wait. Further when I got the editor it had your data in its memory. If you caused the editor to crash neither you nor I could ever use it again. Gnosis is good at sharing but this is too much.

This represents a pitfall in that the easiest way of installing an editor is the wrong way. This manner of installing an editor may, however, be just what is required if there were some specific file that was to to be accessed by several individuals one at a time.

In Gnosis we can install an editor in either mode {and several that haven't been invented just yet}.

The "weaken" call {(p2,rcweaken)} can produce a key that can fetch keys from a collection but is unable to modify the collection.

If one uses the registry {(p2,registry)} to build a tree of directories it is tempting to think that a weakened key to the root is unable to influence the leaves of this tree. Not So! If X is the weakened root key and Y is sub-directory of X then X may be used to fetch Y which, in turn, may be used to modify members of Y.

See (p1,parmcall) or don't accept parameter strings into segments with strange keepers and don't accept parameter strings into pages not yet stored into by your program.