[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 10:53:53 +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)

At Sat, 15 Jan 2005 19:56:09 +0100,
Marcus Brinkmann wrote:
> At Fri, 14 Jan 2005 14:16:57 -0500,
> Neal H. Walfield wrote:
> > I have been think about inhibition.  Why do we need to cancel extant
> > RPCs when we inhibit RPCs?
> To unblock blocking RPCs.  Non-blocking RPCs may not have any
> cancellation points and will just complete.
> Note that the whole issue of cancellation and so on is mostly about
> blocking operations, like select (although as we discussed recently,
> revoke is a special case that also needs substantial consideration).
> A complete non-blocking design would make a lot of things easier, but
> some things quite impossible (like, well, select()-like operations, or
> just blocking reads).

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.


reply via email to

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