[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.
Yes.
Thanks,
Marcus
- Reliability of RPC services, Marcus Brinkmann, 2006/04/21
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/21
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/21
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/21
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/22
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/22
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/22
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/22
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/22
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/29
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/30