[coyotos-dev] Alternative to activation handlers

[Jonathan S. Shapiro]

The implementation of activation handlers is starting to look
complicated. At the moment we still plan to do it, but I wanted to
document the following alternative in an email in case we decide to back
out.

The activation-based design does three things:

  1. Background message delivery
  2. Notification of more pending messages
  3. Preemption, providing support for user-level thread scheduling.

It is the last feature that drives the replicated register set and is
making our life a bit painful on IA32 -- I'm getting concerned about IPC
performance.

An alternative would be to drop the thread preemption feature. If this
is done, then FCRB's would deliver in the background just as they do now
and **enqueue** themselves on the target process. The target process
receives the FCRB payload by executing an explicit receive().
Notification of pending messages can be accomplished via a single shared
word between the kernel and the target process. A new capability slot in
the FCRB structure could be used to maintain a linked list of enqueued
FCRBs.

This design would be sufficient to resolve the issues we ran into in the
EROS networking stack. It has the advantage that it is significantly
simpler than the activation mechanism because a process does not require
two contexts.

I'm not proposing that we switch. I'm merely noting that an alternative
exists.


shap