This is an attempt to solve a covert channel problem. In this note “new” refers to the events in the scenario, but “new” refers to system features proposed by this note.

If a factory is requested to produce a new widget and cannot promptly get enough space, what is it to do? If it it were to invoke an unprompt bank it might become indefinitely unavailable to other clients. If it invokes a prompt bank that might respond with “not now but maybe later” then here is a scheme that may work. The factory domain adopts a new prescient state introduced in this note. This state is independent of the states available, running & waiting. It does not need to change in the lifetime of a domain as I see things now.

I adopt a new resume key terminology here. Any domain that “thinks about” invoking a prescient domain is magically suspended just before it invokes. It is magic in the sense that it is suspended by new rules that we propose here. When the factory is indeed available, it receives the message but with a resume key to the invoker no matter what the mode of invocation. The invoker goes into the new detained state. This state is a new member of the disjoint states: available, running & waiting and an alternative thereto.

At this point the factory which is designed to avoid being blocked, can properly contend with a “not now” response from the bank but first we discuss the normal case. When the bank supplies the requested space the factory releases the requestor by invoking the new release tool sending the resume key for the requestor. This changes the state of the requester from detained to whatever state it expected from its mode of invocation, and returns the original last key that would have been passed had the keeper not been prescient when it was invoked. (It embodies the kernel routine “handlejumper”.) This is the key that is passed to the factory yield and will typically be used to return to the requestor when construction is done.

If the bank replies “not now” to a space request, the factory responds by invoking the bank with a newly invented order to attempt more space, passing the resume key to the requestor as the continuation. Before it does this, however, it operates upon the continuation with the (closely held?) release tool which changes the requestor from the detained state to the impervious state. The factory is now free to become available for other clients. If the bank’s keeper acquires more quota, it returns to the modified continuation with no message and the requestor tries once more.

If, on the other hand the bank has the space the first time, it returns to the resume key to the invoker, presumably with the returner. A message addressed by a resume key to a detained domain “does the right thing” depending on the original mode of invocation as follows:

Call
normal invocation logic—assume entry block in place.
Return
Put invokee in available state and deliver message to domain (or kernel object) denoted by the resume key that is the last key passed by the current exit block of invokee.
Fork
Like Return but put invokee on CPU queue.
We must consider the trouble maker in the confined environment who invokes the factory many times, in a DoS attack. He might even use the same domain as invoker by changing its state with the domain key. Assume a one-to-one relationship between the bank and its keeper. Assume a busy bit shared between these two and that the keeper has write access and the bank has read-write access. The bank sets it just before it invokes the keeper. The keeper resets it just before it invokes the continuation to the detained requestor. If the bit is already set when the bank comes to set it, the continuation is merely invoked rather than passed to the keeper.
Then again there are the decongesters for the stall and ready queues.
This as yet unnamed kernel object, xx, that operates on a resume key to detained a domain, works as follows.

If r is not a resume key then xx(0;r=>−1) and xx(1;r=>−1). If r is a resume key to domain D and D is not detained then xx(0;r=>1) and xx(1;r=>1). If r is a resume key to a detained domain D then (now we must decide how to determine the original state. Is it necessary to remember what the original mode of invocation was, or might we that the domain state is it is now? I don’t see a security issue here. It is akin to how the hardware does handles interruptible instructions.)

Compare with this.