I currently (2002) favor another counter in the <a href=Meters.html>meter</a> that is a quota of processes.
The <a href=m/49.html>decongester</a> 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:<ul>
<li>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:<ul>
<li>Create a domain
<li>start it running until it blocks and invokes the meter keeper,
<li>The trouble maker deletes the domain.
</ul>
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.
<p>Some valid applications may fit this pattern.
<li>The decongester might thus be avoided.
</ul>