[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rpc inhibition

From: Neal H. Walfield
Subject: Re: rpc inhibition
Date: Tue, 18 Jan 2005 15:02:35 +0000
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

> 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!).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]