In order to distinguish the factories under consideration, we call the first factory the PF (prime factory) and one of the possible components of PF we call SF (sub factory).
We must be precise here by what we require of a prompt factory. A factory has processed a request when it has created a new domain, destined to execute the confined program and becomes available for a new request. A factory is prompt if invoking its requestor’s key for a new instance is not indefinitely delayed by a previous such request. Factories are prompt in this sense. The return key to the requestor is delivered to the new domain that normally returns to the requestor after the new object finishes initializing itself. Bugs in the confined code, or unusual designs may mean that the requestor is never returned to.
The first observation is that in order to keep PF prompt, the new domain D is created by PF and D executes code to invoke SF. SF, being an official factory, is guaranteed to quickly accept new creation requests via its requestor’s key, but may not return promptly for that depends on the .program of SF. Thus PF cannot wait on the return from SF to become available for new requests. Deputizing D to invoke SF solves this problem. It also solves the problem of exhaustion of the meter supplied via the requestor’s key to PF.
The code that the newly created domain executes to invoke the factories seems simple enough but recent experience suggests that it should be user replaceable. This has these benefits:
This change is slightly incompatible with some current factory building code.
It is possible, though unlikely, that some factories would pass the limit of 19 components and thus require the fetcher factory hack.