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:
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.)