Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Wed, 2006-04-26 at 18:45 +0200, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 25/04/2006 hora 13:56:
> > > checking that the capability is still usable seems to me to be much
> > > complicated
> > This check is already necessary in the specification.
> 
> Could you point me where it is further described in the Coyotos
> specification (I'm reading it a bit in random order)?

Yes. Look at the specification of the 'pm' bit and the 'bl' bit in
section 3.2. Then look at the specification of the 'rc' bit in section
5.1.1. The combination of auto-blocking and a fast means for the client
to change the FCRB payload can be use to create reply-at-most-once
capabilities.

> > > this check would need to page in the FCRB
> > So does severing the FCRB.
> 
> Yes, but not at the same time.

I do not understand.

> 
> When C is eventually asked to cancel the operation, it will sever the
> reply FCRB to itself. The capability to the FCRB then becomes a null
> capability. C and anything from it can be paged out, it is not needed
> anymore.

In general, the only subsystem that has permission to sever is the
storage allocator. C can *request* that the object be severed by
returning it to the allocator. This is a multiple-IPC sequence. It is
better and faster to just update the payload if what you are trying to
accomplish is to block the second and subsequent replies.

> Some time later, S notices that it's capability is null, and can recover
> without the need to page C in, not even the FCRB.

But this requires periodic polling, a.k.a. a watchdog. In which case,
why not use the watchdog in the first place!


shap