Re: Cancellation forwarding protocol (was Re: Reliability of RPC services)

[Jonathan S. Shapiro]

On Thu, 2006-04-27 at 19:37 +0200, Pierre THIERRY wrote:
> > A capability is considered invalid exactly if:
> > 
> >   1. The target object that it names has been destroyed (severed), or
> >   2. The capability is a sender capability to an FCRB, the PM bit of
> >   the FCRB is set, and the PP does not match the PP of its target.
> 
> Then the specification is incomplete, IMHO. Section 6.1 tells that
> invoking a capability with wrong PP where there is PM triggers an
> InvalidCap exception, but nothing tells that the cap in itself has
> become a void capability, and that discrim would see it that way.

Thank you for pointing this out. I will make sure that this is
clarified.

> > Does my description above answer your question?
> 
> Almost completely. Will coyotos.cap.getType() return the ID of a void
> capability, or only Discrim could see the invalidity?

At the kernel level, Coyotos.cap.getType() is an invocation on the
capability. If the PP does not match, it will report ctInvalid.

However, if the PP *does* match, it will send a message to the receiver,
with the side effect of causing the capability to become invalid. This
is a necessary consequence of having "use once" capabilities.

Because of this, the operation that you want here is Discrim.

HOWEVER!!!

This case is so universal that there will be a safeGetType() method on
the discrim interface. Discrim.safeGetType() will perform:

   {
        if (discrim.classify(theCap) == ctInvalid
           return ctInvalid;
        else
           return theCap.getType();
   }

This is actually implemented at the library level, and I had forgotten
about it.

Does this help?