Re: rpc inhibition

[Neal H. Walfield]

> For these cases, we might be better off using continuations.  For
> select, we are going to need bits in the capability object indicating
> that a thread is waiting for events on the underlying resource.  The
> implementation w will be more complicated than a single condition
> variable if we allow a single thread to listen for events on multiple
> capability objects (or we will need a single condition for all events
> which would suck).  Using a continuation also has the advantage that
> we don't have the overhead of a 2kb tbc and the corresponding stack.


A few details follow which I think are worth mentioning explicitly.

If we go this route, we will need to have a per-capability object
class call back to cancel continuations when a revoke is done on a
capability object.  A feature of this call back would be which
continuations NOT to cancel: either none (in the case of e.g. a
hurd_cap_bucket_end) or a specific thread (for when, e.g., an
io-revoke is issued on a capability).

Continuations have to keep a reference to the underlying object and
client (which is intuitive as the server has to know to whom it must
send a reply when the event in quest occurs) and need to be cleaned
ups in response to a task death notification.

We shouldn't need to cancel continuations when a class is inhibited if
continuations retake the inhibition lock before servicing the event in
question.  This is useful if a lot of threads have extant select calls
as then we don't have a stampede of newly awoken threads (and all is
different tasks!).

Thanks,
Neal