[coyotos-dev] Activations

[Jonathan S. Shapiro]

On Tue, 2007-05-22 at 10:02 -0400, Christopher Nelson wrote:
>         Given that the same functionality can be accomplished with a
>         same-space
>         "external" handler, and given also that there appears to be
>         no 
>         performance advantage to activation handlers because of the
>         capability
>         register issue, I have two questions:
>         
>           1. Do you still feel that activation handlers are motivated?
>           2. Do you see any examples of real things you want to do
>         that cannot 
>              be handled with an external fault handler that shares an
>         address
>              space with the "base" process?
> 
> Hmm. Well, having given it some thought, I think that the space
> sharing fault handler still has a problem that the activation handler
> does not: that being the need to be multiplex.  My concern here is
> that a single dispatching fault handler for many processes and/or
> threads introduces a single point of failure.

I think that there may be some confusion.

For external handlers, the model is that each process specifies its
external handler independently. There is a capability slot in the kernel
process structure. You specify the handler for your faults by installing
an entry capability into this slot. Whether the handler is multiplexed
is determined by how you choose to set up your handler. This can be 1:1
or 1:N.

The handler is simply a process. It gets a message about the fault and
chooses whether to do something about it.

The handler is not system-wide, so it is not a global single point of
failure. Further, the handler process itself may specify a handler.

>   How do threads and processes get their faults?  If they are posted
> to a queue for each thread/process, okay, but then the queue still has
> to be checked and involves requisite overhead.

In Coyotos, it is not possible for a process to have more than one
pending fault at a time. For this reason, there is no need for a queue.

When a process incurs a fault, several things happen:

  1. A fault code (equiv. to exception code) and a fault info value
     are written to the process state.

  2. The faulting process has a handler slot that contains either
     an entry capability to the handler or Null. If it contains Null,
     the faulting process ceases to execute instructions. In effect,
     the developer has declared that faults should not be handled.

     If a handler capability is later installed, the fault will be
     delivered at that time.

  3. Assuming that a fault handler entry capability is present, the
     kernel IPC to the handler, supplying the integer register set,
     fault code, and fault info to the handler. Also supplying a
     capability that allows the handler to restart the process.

     It is rarely necessary for a handler to know the identity of
     the faulting process. When this is necessary, it can be handled
     by using distinguished protected payloads in the respective
     handler entry capabilities. This suffices because the PP of
     the invoked cap (in this case the handler cap) is provided to
     the receiver.

  4. If the handler process chooses to resolve the fault, it does
     whatever action may be appropriate and then uses the provided
     capability to resume the faulted process.

  5. There is no requirement that the handler share an address space
     with the faulted process. The reason I was discussing this
     arrangement is that it corresponds most closely to the activation
     handler approach.

>   If the fault handler immediately dispatches the fault to the
> appropriate thread/process handler, then those handlers could die or
> hang or otherwise take far too long causing cascading problems to
> other threads and processes depending on that central fault handler.  

There is no central fault handler.

Concerning failures of fault handlers, yes, they are possible. In *any*
system, there is some code that simply must be correct. In Coyotos,
certain fault handlers fall in to this category. This is also true for
in-kernel fault handling policies. The difference is that an external
fault handler 

> It also seems like it could induce false sharing between independent
> threads and processes, where delays in fault handling by other threads
> or processes could cause those to propagate and slow down groups who's
> processing is otherwise unrelated.  Of course, this assumes that you
> are using these handlers for various types of notification (like
> memory mapping / etc.)  

Now that it is clearer how the fault handler works, do you still have
this concern?