Meters may themselves hold meter keys from which they get their authority to consume CPU resources. This chain terminates in a special magic meter key that works even though it does not designate a real meter. For a domain to run there must be an unbroken chain of meters from the domain to the special meter.

Each meter has a number in it that runs backwards as domains below run. When that number reaches zero the domain stops running and an exception message is sent via a key found in that meter’s keeper slot. This key is normally a start to user code called the “meter keeper”. The message includes a service key to the meter which lets the keeper change slots in the meter. The meter keeper is thus able to get control as resources are consumed under the meter. The keeper can immediately replenish the counter or can decide not to replenish it until later when CPU resources are less dear.

The meters form a tree with a counter and on-off switch at each node that is accessible to the holder of a meter service key.

The kernel switches about every 10⁵ instructions among domains that are ready for the CPU and have meters with resources. This round-robin effect could be produced outside the kernel but it was very easy to do it in the kernel and expensive in resources to do it outside.

It is sometimes proposed that it would be easier to implement if meters could “hold” consumption rights so that it would be unnecessary for the kernel to find the special meter, up the chain, to run the domain. This model would not provide for turning off some particular computation at a particular unanticipated time. This current meter design does allow for this. The two designs are contrasted by the names the wire model and the battery model. If there are batteries in the system one cannot turn things off selectively and promptly. There is a trade-off; if one makes small grants of fuel, then these effects are limited. One must then be able to determine who has unused fuel whose consumption might come at a time when CPU cycles were critically short. The Engines available in some varieties of Scheme are a form of battery. One can do time slicing with meters but not batteries. We did time-slicing in the kernel because it was not efficient to do it with meters, and besides, we didn’t think of it then.

I currently (2002) favor another counter in the meter that is a quota of processes. The decongester has not been implemented and might well be a bad idea. The fork invocation would reduce this quota and cause a trap much like the exhausted cycle limit trap. There are at least these reasons why the meter keeper might be concerned with the number of processes in the realm that it controls:

• Trouble makers might create domains for the sole purpose of getting an “unfair” amount of CPU cycles. This is perhaps possible due to the simple round-robin nature of the primitive kernel scheduler. Some scheduler strategies by the meter keeper would thwart this but other attractively simple alternatives would not. Other trouble makers might repetitively:
  • Create a domain
  • start it running until it blocks and invokes the meter keeper,
  • The trouble maker deletes the domain.
  This delivers a resume key to the meter keeper who may attempt to accumulate these keys so to avoid locking the domain roots in RAM. This collection of resume keys is thus mostly empty.

  Some valid applications may fit this pattern.

• The decongester might thus be avoided.