l4-hurd
[Top][All Lists]
Advanced

[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: Sun, 23 Apr 2006 20:23:14 +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 Sun, 23 Apr 2006 04:17:46 +0200,
Pierre THIERRY <address@hidden> wrote:
> So what should C do to avoid memory leaks (he asks for something through
> a capability, providing the space for the answer, and never gets
> anything, probably several times) or freeze (when waiting for an answer
> to continue it's work).

Well, Jonathan points out to us that there are other failure modes as
well, and my proposed solution does not address these.  So, one useful
question to ask is: What does C do to avoid _any_ memory leaks?  Or
rather: How do you recover from any memory leaks in a server or
long-running application?

In a persistent system, this is an important question independent of
the discussion in this thread.  So, backing off a bit, one could argue
that you need a protocol to "restart" a service in place with a new
version (or a sanitized copy of the same version), and that this could
also be used to recover from the failure I described.

However, I am worried that in a system which needs to run malicious
code on a regular basis (browsers, video codecs etc), we face a
challenge of usability: How to identify the programs we need to take
care of?  I can imagine that a user will eventually be able to
identify a badly behaving application in the process list (like a
browser) and shoot it down.  However, I can not imagine that a user
can identify a leaking directory server, for example, and know the
right steps to maintain it properly.

The problem is that neither bugs nor malicious code can in principle
be contained to some set of applications.  This is a serious
challenge.

Detecting bugs and malicious code is a serious challenge as well, of
course.

> In some cases, I suppose human intervention is possible, like when a
> process waits for a device driver to perform (typically disk write) that
> cannot, but that's not suitable everywhere. There are many cases where
> we could expect the system to recover nicely by it's own. Are timeouts
> to be avoided most or all of the time? What are the alternatives?

These are the things to think about.  Real time systems can give us
insight into how to write a system that work well with time outs
present, for example.

Thanks,
Marcus






reply via email to

[Prev in Thread] Current Thread [Next in Thread]