These are ideas almost purely as conveyed by Jonathan Shapiro.
I have talked to him on the phone several times, the most recently in the last hour.
They concern how domain code that multiplexes some facility can efficiently
order its work.
(More work is needed here to specify the problem better.)
Here are the proposed kernel design changes as I understand them.
This is entirely from the extra kernel perspective even though
the internal designs are in fairly plain view.
There is a newly architected domain root slot R that, like the brand slot, is inaccessible via the domain service key.
This slot is void while the domain runs.
There is a newly architected retry kernel invocation that is much like
those the key jump family.
Retry designates a key that we will assume here is a resume key.
It also designates a smallish piece of data, ID, perhaps 8 or 16 bits long.
The exit block also designates a “redirect key”.
In the intended use the domain will become available as its next action and
perhaps this should be the outcome of retry,
in which case an entry block will also be specified by retry.
The redirect key will be placed in slot R of the waiting domain specified
by the resume key.
That domain enters the milling state, a new state in the running, waiting and available suite.
The milling state is busy, i.e. not available.
In the intended use the redirect key will be a wrapper key for a node whose format key
(2016):
The above breaks off in mid sentence.
I cannot finish the idea just now.
I do remember a specific problem in this area however.
A program S has been called and holds a return key R to some caller.
The caller has asked for something which S cannot provide just now.
However S can take action which will probably lead to circumstances where S, were it called again, provide the action desired by the caller.
S is not in a position to remember the request, however.
Perhaps S could take some as yet unarchitected action on R to cause the caller to go into the stalled trying to send the same message again.
This action causes the caller to execute no instructions.
The kernel frequently does this so as not to have to allocate storage to remember what it is doing.
This helps the kernel avoid threads.
It might be the correct action of a non-prompt space bank before it invokes its bank keeper.