There are a few small features I would like to change about the Keykos kernel.
Lazy Loading of floating state
Perhaps the floating point state of a domain should be an option. Independently, perhaps domains should not run with access to the floating state unless floating commands are indeed encountered.
Optional General Keys Node
Current Keykos kernels provide a bit in the domain that prevents key invocations when set. It would have been cleaner to merely fault the domain when it attempts invocation with no general keys node, and not otherwise require a general keys node. The domain that obeys code designed for Unix may need no general keys node. This also makes a sealed box one node smaller.
Shrink available state
This is perhaps not worthwhile but it should be noted that only a few registers are needed as an available domain begins considering a new request. Conversely when it returns only those registers need be saved. I think we considered this on the 370 but it didn’t seem important. Which registers need be saved depends on the habits of the compiler you use to make the domain code. The registers that are not restored must be cleared of garbage and probably set to zero. This is not much less expensive than loading them, at least on the machines which have run Keykos. The change would have been a step towards manifestly immutable objects.
Resume key overhaul
Two options that are logically independent but make sense to do together: I think this is both easier to code and easier to understand. Further, I cannot now imagine why we didn’t think of doing it that way in the first place.
Blocking Send
Shap proposes that an exit block explicitly devote a bit to specifying whether, on key invocation, to tolerate being blocked by the logical state of the recipient. In the current design invoking a start key blocks the invoker until the domain is available whereas invoking a resume key is guaranteed to be prompt—i.e. require no actions beyond what the kernel can carry out. The returner was invented to give a program an easy way to guard against being blocked when invoking a key that should be a resume key. An exit block bit would be explicit and generally lighter weight. I would keep the returner—I like it. It would no longer be needed for its original purpose. Presumably invocations of resume keys would block if the bit were not set, and start key invocations would be nullified if the bit were set and the invokee were not available. In general the invoker must not be notified of a discarded message for it is a counter-flow signal. Shap’s version notified the sender and he has a use case that warrants this. More design is needed. This also supports tail call where a domain wants to return to a start key, passing its resume key, to let some other domain compute the final answer to its caller.
Limiting Process Count
See this and this
Push-back
Objects implemented in the kernel have the option of pretending that they did not hear an order until such time that it is possible to obey the order. The orderer can be put on a kernel queue. Domain implemented objects could use this too. See Shap’s proposal and resulting mail. See too a later thread.
Sever
SSD, Shingled Disc, NVRAM