To each RO there is a draw capability to draw on the resource, and a service capability to control the allocation that the RO provides. Both of these types are hierarchical so that with a draw capability to a RO, a service key to a subservient RO can be had. Resources drawn from a subservient RO are drawn, in effect, also from the superior RO. If RO X is subservient to RO Y then resources drawn from X are drawn, in effect, also from Y.
The capability signatures are not polymorphic and this is how we map for this unified description:
draw capability | service capability | |
space bank | buy and sell rights | destroy bank |
meter | “meter key” | node key to underlying node |
Generally only one user, SYSADMIN, would introduce a new user by invoking CUA. SYSADMIN would typically create 2 new subservient ROs for that user and put draw capabilities to them in the directory. The directory might well include a capability to the CUA along with access to other harmless system facilities. SYSADMIN also retained the service keys to the ROs of each user and a trivial program would invoke these at anytime for a current usage report. If another user were to create an account on his own he would have to draw on his own ROs.
The CLI objects provide a multi-concurrent-environment facility called branches. Normally a debugger would create a branch of his environment as a sandbox. The CLI automatically produces subservient ROs for this branch and a new directory with draw capabilities to these. When the program died without giving back all of its space the branch was zapped which caused the CLI to zap the ROs but not before reporting missing pages and nodes.
If a complex application is losing pages or nodes it may create a few sub-banks and only distribute those. This makes it easy, if not immediate, to track down leaks.