l4-hurd
[Top][All Lists]
Advanced

[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: Tue, 25 Apr 2006 06:50:22 -0400

On Tue, 2006-04-25 at 10:32 +0200, Michal Suchanek wrote:
> On 4/25/06, Jonathan S. Shapiro <address@hidden> wrote:
> > On Mon, 2006-04-24 at 23:58 +0200, Pierre THIERRY wrote:
> 
> > 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.
> 
> If there can be only one copy of the capablity you obvoiusly cannot
> move it by first making a copy and then overwriting it. You need a
> move operation for that.

Yes. I am defining the internal behavior of the move operation. This
needs to be defined because the internal behavior dictates when things
are invalidated, so we need to know precisely what the rules are.

> > 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.
> 
> How is it invalidated by send if there are multiple copies? Who finds
> all the copies to invalidate them?

It's called an "allocation count". There is no need to hunt down the
copies.

shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]