[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Bas Wijnen |
Subject: |
Re: Reliability of RPC services |
Date: |
Tue, 25 Apr 2006 23:54:15 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
On Tue, Apr 25, 2006 at 12:19:53PM -0400, Jonathan S. Shapiro wrote:
> On Tue, 2006-04-25 at 16:25 +0200, Bas Wijnen wrote:
> > On Tue, Apr 25, 2006 at 10:03:56AM -0400, Jonathan S. Shapiro wrote:
> > > So I pose the following test case:
> > > ...
> > > 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.
> >
> > I disagree. Although it seems likely that a watchdog (possibly in the
> > form of the user himself) is needed for servers entering infinite loops, I
> > don't think this is an adequate solution. There just isn't anything
> > better, so we'll have to accept it anyway. That doesn't mean we must
> > accept it as a solution for situations where good alternatives exist as
> > well, though.
>
> Certainly not. What we must accept is that *any* solution we have
> identified has problems. The question is: how many bad solutions to
> different parts of the problem must we accept simultaneously?
Not exactly. The problems of timeouts are limited to when they are used.
That is, if we don't use timeouts in certain situations, then their problems
don't hurt us in those situations.
This is different from single-copy capabilities, where the problems do impact
situations when they aren't used. I suppose this is the reason you don't like
them.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
- Re: Reliability of RPC services, (continued)
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services,
Bas Wijnen <=
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25