[coyotos-dev] Preemption again

[Valerio Bellizzomi]

On 04/02/2008, at 15.37, Jonathan S. Shapiro wrote:

>I remain dissatisfied with the current (lack of) preemptive
>notifications in Coyotos. Enough so that I want to revisit the issue.
>
>The primary need arises from watchdog timers and the desire for
>in-process exception handling for things like memory faults.
>
>What we actually want is a mechanism in which:
>
>  1. A constant-state notification can be delivered to the target
>     process.
>
>  2. The target process can take notice of this delivery *without*
>     irrevocably disrupting anything that it is currently doing --
>     most especially any pending closed wait (which is the main
>     complicating factor).
>
>  3. There is a mutual exclusion between the "notice handler"
>     and the primary processing path.
>
>  4. There should be a mechanism allowing a process to efficiently
>     defer preemption.
>
>  5. It is not required that the mechanism nest in the style of UNIX
>     signals.
>
>I abandoned this whole issue after concluding that the exception handler
>needed to have a complete capability register set, and therefore might
>as well be a process in its own right. In particular, there was no space
>savings to be had from any sort of activation handler.
>
>I am now considering the whole thing once again, and once again looking
>for a reasonable solution. Looking at the requirements above, the only
>one that is a bit tricky is the mutual exclusion requirement. More
>precisely, the interaction between mutual exclusion and avoiding any
>interference with closed wait.
>
>I am now contemplating what might be termed a "proxy entry" capability.
>Here is a behavior sketch:
>
>  1. There is a new type of entry capability called a "proxy entry"
>     capability. This is basically an entry capability with a currently
>     unused bit set.
>
>  2. The effect of invoking a proxy entry capability is as follows:
>
>     A. The target process is marked "not schedulable".
>
>     B. The reply capability provided by the sender, if any, is stored
>        into a dedicated slot of the target process.
>
>     C. There is a new slot ProxyReceiver in every process. If used,
>        it must contain an entry capability. Any message send to a
>        ProxyEntry capability is delivered to the process named by the
>        ProxyReceiver. In place of the original reply capability,
>        the ProxyReceiver receives a process capability to the process
>        named by the ProxyEntry capability.
>
>  3. New mechanism is added to the Process capability allowing fetch
>     of the ProxyEntry slot and clearing of the "not schedulable" bit.
>
>
>The alternative design seems to be:
>
>  Simply give out an entry capability to the ProxyReceiver directly.
>  Let the ProxyReceiver render the original target "not schedulable" by
>    hand.
>
>This may be simpler, and it introduces minimal new mechanism.
>
>
>Reactions and thoughts?

Keep it simple.

val