Re: rpc inhibition

[Marcus Brinkmann]

At Tue, 18 Jan 2005 15:02:35 +0000,
Neal H. Walfield wrote:
> 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).

I think there can not be a difference between what you call
"continuations" and normal RPC worker threads.  They must behave in
the same way.

What we need is a more generic mechanism - to forward cancellations
(either as requested by the user, or internal cancellations because of
revocation etc) to the new handler thread.  Note that there always
_must_ be a handler because the client thread does (supposedly) a
closed wait on a specific thread.  That thread is the handler that
should receive the cancellation according to some protocol of our
choosing.

I always thought that this would be implemented in the sort of some
local manager, to which the current RPC is "forwarded".  The
cancellation request would then be forwarded to this manager via LIPC.

If that thread is using cancellations internally to implement certain
mechanisms is not relevant, as long as cancellation etc will still
work as with any other RPC.
 
> 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!).

That's just not true.  We will have to cancel all pending RPCs if the
class is inhibited.  That's the definition of inhibition, and select()
is no exception (there is no exception).  If you think about the
actual applications for class inhibition (like remounting), you will
see that it doesn't make an actual difference.

Thanks,
Marcus