Re: Reliability of RPC services

[Marcus Brinkmann]

At Tue, 25 Apr 2006 10:03:56 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Tue, 2006-04-25 at 13:06 +0200, Marcus Brinkmann wrote:
> > However, I am _much_ more interested in discussing what the actual
> > problem is we are trying to solve.  It has to do with recovery...
> 
> I agree. Also, there is something else that we all agree on: if one
> mechanism can handle two problems with acceptable efficiency, it is a
> mistake to introduce a second mechanism for the second problem.
> 
> So I pose the following test case:
> 
> Suppose C calls S, and S enters an infinite loop. How should the client
> defend itself from this error? Notice that none of the "capability death
> notice" ideas are helpful.
> 
> The only mechanism that I know about that can guard against this is some
> form of watchdog (which is why I am backing away somewhat from my
> earlier position about watchdogs).
> 
> If we conclude that we need watchdogs for this (or for something else),
> then I suggest that kernel-supported capability death notice (any kind)
> is unnecessary and should not be implemented.

There is another mechanism, which is user interaction.  From the
beginning, I have required a user to either kill S, or cancel C (or
both).  So far I have put my emphasis on "killing S", which gave me a
50:50 chance of being right ;) But I am slowly backing off and want to
consider cancellation at C more seriously, because this is actually
more natural.  Of course, it is also possible that I am considering a
non-problem, so I want to take a closer look at very specific (as
opposed to abstract) test cases as well.

If user interaction is not admitted to the problem, then I agree that
it seems that upper bounds on wall clock time are indispensable.
However, I would not rush to this solution: It seems to me that an
attempt to get _that_ alternative right and proper drags you very
quickly into real-time wonderland, where I am mostly ignorant, and
investigating that route will probably put us off by another couple of
months.

Thanks,
Marcus