[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Jonathan S. Shapiro |
Subject: |
Re: Reliability of RPC services |
Date: |
Mon, 24 Apr 2006 20:48:57 -0400 |
On Mon, 2006-04-24 at 23:58 +0200, Pierre THIERRY wrote:
> .
>
> We have a serious communication problem here. Noone uses the same set of
> definitions for capabilities in the discussion. Please state as
> precisely as possible the type of capabilities you're thinking of in
> your scenarios.
I don't think we disagree about the definition of capability. I think
that there are several conversations that make different assumptions
about the word "delegate".
So perhaps it would be good to emphasize:
delegate (by copy)
vs. delegate (by move)
Finally, we should understand that "by move" is really "by copy followed
by overwrite with void". This is necessary in order to understand the
semantics of "dropping" a capability. If this is not the intended
behavior, then the intended behavior needs to be stated.
Concerning "reusable vs. send once": All reply capabilities are
invalidated by send. This is necessary in order to guarantee that every
call receives at most one reply. This is, in fact, the *only* difference
between a reply capability and a send capability.
shap
>
> For the moment, we have:
> - copyable vs. movable only
> - reusable vs. send-once
> - with drop/last drop notification or not
>
> and I think nearly all the 12 combinations of these ones have been used
> in the thread. That has become a misunderstanding nightmare.
>
> Please please describe which caps you think of.
>
> Combinatoricly,
> Nowhere man
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd
- Re: Cancellation forwarding protocol (was Re: Reliability of RPC services), (continued)
- Re: Cancellation forwarding protocol (was Re: Reliability of RPC services), Jonathan S. Shapiro, 2006/04/28
- Re: Cancellation forwarding protocol (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/26
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/24
- Re: Reliability of RPC services,
Jonathan S. Shapiro <=
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/24
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/22
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/22
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/22