[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rpc inhibition
Neal H. Walfield
Re: rpc inhibition
Tue, 18 Jan 2005 15:02:35 +0000
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