Revocation vs destruction

[Marcus Brinkmann]

At Thu, 13 Oct 2005 22:04:20 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
>   REVOCABLE COPY
> 
>                            L4     EROS/Coyotos  Notes
>   Primitive?               Yes    No            [1,6]
>   Delegatable revocation?  No     Yes           [3]

Just as a side note, _if_ you can make a copy of your capability, you
could delegate the revocation right in L4 by deriving the revocable
copy from your own copy, and then grant your copy to some other
process.

But I have a different question.

One issue that keeps confusing me is the distinction between object
destruction and revocable copies of capabilities.  You stress that
explicit object destruction is important.  You say that revocable
copies is sometimes a desirable feature, but in general it's not
common at least in EROS.

In the plans for Hurd on L4, we do not emphasize explicit object
destruction, as we use reference counting (for almost everything).
However, we do have some emphasis on revocable copies.  This is a
direct influence of the L4 map/grant/unmap model, of course.

I have some difficulties in determining what the practical differences
are between the two models.  Revocable copies allow selective
revocation, which seems potentially more powerful.  Also, they
preserve the original object, which might be an optimization (if the
object state can still be trusted after it was used by the receiver of
the now revoked copy).

"Normal" copy and object destruction allows the receiver to verify the
type and origin of the object, and thus trusts its implementation.
OTOH, if revocable copies are pure forwarding objects, and the
instantiator of a revocable copy can not intercept the messages, then
verification of implementation could equally done for the revocable
copy.  The receiver only needs to know if the object is a revocable
copy or not to determine if it needs to deal with object destruction
(in the case where the sender has no direct object destruction right,
but only revocation rights for the revocable copy).  The
implementation would be identical, due to the forwarding property of
the revocable copy (which can be guaranteed by the kernel).

In the case where the user does have object destruction rights, both
types of copies can be invalidated anytime, and the receiver has to
take it into account.

But I am not happy with this characterization, at it is purely
phenomenal, and doesn't really connect with the actual use cases and
design patterns at a global scale.  My question is thus, what is the
real functional difference between the two?  I think one of my
problems is that I am pretty familiar with the design patterns with
map/grant/unmap, having spent some time thinking about them.  But I am
not familiar with design patterns employing explicit destruction, and
trusting the implementation of objects.  Maybe there are some typical
examples which show where explicit destruction (or the inability to
destroy a copy!) is a big plus over revocable copies?

Feel free to reinterpret my questions to make them more meaningful :)

Thanks,
Marcus