[coyotos-dev] Preemption again

[Godfrey Vassallo]

Here is a knee jerk reaction.
 
I think that a designer would want to bind a preemptive notification to an important event that is somehow related to the target process. It seems counter intuitive to send the notification to a proxy process which then will need to somehow interact with target process to make the occurrence of the event know. I assume that proxy knows how to handle the event and only needs to report its occurrence to the target. Implicit actions seem to make debugging tricky and code difficult to understand, especially when the action is subtle. Explicitly suspending and reactivating the target process will aid program comprehension by both current and future maintainers.
 
Godfrey

 
________________________________

From: coyotos-dev-bounces at smtp.coyotos.org on behalf of Jonathan S. Shapiro
Sent: Mon 2/4/2008 3:37 PM
To: coyotos-dev
Subject: [coyotos-dev] Preemption again



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?


shap

_______________________________________________
coyotos-dev mailing list
coyotos-dev at smtp.coyotos.org
http://www.coyotos.org/mailman/listinfo/coyotos-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6667 bytes
Desc: not available
Url : http://www.coyotos.org/pipermail/coyotos-dev/attachments/20080204/afbc6af0/attachment.bin