[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reliability of RPC services

From: Marcus Brinkmann
Subject: Re: Reliability of RPC services
Date: Sat, 22 Apr 2006 03:53:49 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Fri, 21 Apr 2006 20:23:41 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> On Sat, 2006-04-22 at 02:09 +0200, Marcus Brinkmann wrote:
> > At Sat, 22 Apr 2006 01:42:41 +0200,
> > Marcus Brinkmann wrote:
> > > In the upcoming L4 versions, and in Coyotos, destruction of the
> > > receiver of a reply capability does not cause any action to be
> > > triggered: Pending RPCs are not aborted.  This is because there is an
> > > extra level of indirection between the reply capability and the thread
> > > (first class receive buffer).
> > 
> > Clarification: FCRB here is meant as a synonymous for thread (one is
> > an L4 term, the other a Coyotos term).  The indirection is of course
> > the endpoint.
> Marcus:
> I believe that you may need to look at the FCRB specification more
> carefully. An FCRB is bound directly to some receiving process (which is
> equivalent to a thread). There is no additional endpoint. If we can
> arrange for the FCRB sender capability to get invoked, that's all we
> need.

Yeah, sorry, I messed that up.  In L4, it is the endpoint that
provides the indirection, in Coyotos it actually is the FCRB.  Which
is to say: Instead of waiting on a remote thread, the calling thread
is waiting on the endpoint/FCRB.

I tried to have one description to losely catch L4 X.2/EROS vs new L4s
and Coytotos at the same time.  In hindsight, that didn't work too well.

> I also want to add one addition to your earlier discussion:
>   We want "reply capabilities" to trigger a death message.
>   We do *not* want "entry capabilities" to trigger a message.
> This means that the kernel must have some way to distinguish these two
> types of sender capabilities.



reply via email to

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