Re: Reliability of RPC services

[Marcus Brinkmann]

At Sat, 22 Apr 2006 14:07:00 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Sat, 2006-04-22 at 19:24 +0200, Marcus Brinkmann wrote:
> 
> > At Sat, 22 Apr 2006 10:22:25 -0400,
> > "Jonathan S. Shapiro" <address@hidden> wrote:
> > > 1. The behavior that you want can *only* be accomplished with reference
> > > counting.
> > 
> > This is not true.  A send-once capability does not require reference
> > counting as only ever one reference is extant (guaranteed by move vs
> > copy semantics).
> 
> We have a miscommunication. I was referring here to the proposal that
> multiple reply capabilities should be permitted to exist, but a notify
> would be sent on the last overwrite.

It's always difficult if too many variations of one idea are discussed
at the same time.  The only option I considered seriously is the
"send-once" semantics, because this does not require reference
counting and, given the requirements I imposed on the solution (good
or bad), seemed to do the job with minimum overhead.

If multiple copies of a reply capability are allowed to exist, then
one can avoid reference counting by sending a "death notice" on
_every_ capability drop, just as the solution you proposed would send
a "death notice" on _every_ capability destroy (not only on the last
destroy).  This is the variation I had in mind when discussing it.

These are the only two options I spend any time thinking about.  The
variation "send death notice on last drop while allowing multiple
capability copies" I rejected immediately because of the need to do
reference counting.

Neither of these two options requires dynamic allocation of kernel
storage.  In fact, neither of them requires any kernel storage beyond
that what is already planned for.

> > However, my suspicion is
> > that without any such mechanisms, no useful, persistent, fault
> > tolerant, user-extensible multi-server system can be built (for some
> > definition of useful, which includes running a browser and sharing
> > files with friends).
> 
> Fascinating, since there is a known counterexample that was used in
> production without a problem for a very long time. Also, note that
> AS/400 doesn't have this either!

I don't know these systems well enough to decide if they fit my idea
of "user extensible" and "useful".  It's worth checking out if they
faced similar challenges and if yes, how they addressed them.

> > > 3. Your proposal seems to have the side effect (I am not certain) of
> > > dictating a hierarchical calling relationship. This is bad.
> > 
> > I am not sure what that is supposed to mean.
> 
> I am concerned that move-only capabilities will tend to encourage a
> structure in which out of order reply is difficult. I haven't thought
> about it, so please do not take this concern too seriously at this
> point.

Ok.  As I said in an earlier mail, I don't know about any other use
case involving more than one process getting the reply capability
except for forwarding.  I'd like to know some.

I plan to also check out kernel models which use "thread
migration"-like invocation mechanisms.  In these systems there also
must be some provision to get back your thread eventually.

Thanks,
Marcus