Re: rpc inhibition

[Neal H. Walfield]

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.

Thanks,
Neal