I have not thought hard about bank keepers recently so this note should be viewed suspiciously. I think I see a solution that seems simpler than I recall thinking was necessary. Sometimes distance from the problem actually helps. Usually it merely leads to muddled ideas.

There is an abstraction in the kernel called the obstacle. It is not exported from the kernel but it is a bit like what the bank needs to defer requests when the keeper cannot clear the way for progress. There are precise kernel invariants connected to bits in the readiness byte of the DIB that record that a particular domain is subject to some obstacle for which there may be headway in progress somewhere towards removing the obstacle. Each bit in READINESS can be computed from other data structures but a domain may not run if any bit in READINESS is 1. The logic manual names the bits and their ramifications.

The current idea is to make it clear that a waiting domain has enough information to reissue the call that led to its waiting state. It need not be guaranteed that the same message will be sent despite mucking with the domain service key or write keys to the domain’s address segment. A start key to a kept bank would acquire some of the mystery that accompanies IO keys wherein a careful observer wielding a domain key to a domain that calls IO keys is in a position to deduce that sometimes side-effects upon the invoked bank happen just before the call issues. The prescient bank would mysteriously prepare to be called as an IO operation seems to start just as the invocation of the IO key is imminent.

The bank keeper holds the resume key to the bank invoker. When the bank decided that the keeper was needed it returned to the keeper becoming available while the keeper acquired the resume key to the invoker with the troublesome request.

The keeper has access to a possibly closely key, defKey, that defers the invoker, largely deferring its execution until a more opportune time. Such a deferred domain is logically running but very sluggishly. Two fuzzy words above; “largely” and “opportune”. First I propose that the kernel is free to run the deferred domain but it will rarely do so except for extreme situations, such as checkpoint restart. The defKey may take as a parameter some sort of category indicator via which it may indicate to the kernel when it is opportune. One model is a simplified version of the wait key without the clock function. Note that the state of the wait object designated by the wait key is not preserved on checkpoint restart. Actually I can see no reason to make a simpler version of wait as the kernel already includes the wait function with its clock function. The bank keeper could use a primitive or multiplexed wait object.

This needs to be reconciled with both Kept Banks and stonewalling.
Bank Obstacle: Kept Banks Keepers