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: Wed, 26 Apr 2006 13:34:47 +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 Tue, 25 Apr 2006 22:46:17 +0200,
Bas Wijnen <address@hidden> wrote:
> I like Shapiro's idea about watchdogs which don't bite, but only bark. ;-)
> (He didn't use that terminology, but I think it's nice. :-) )  In other words,
> the watchdog doesn't kill the process, it just notifies the user that there
> may be a problem with it.  If there is a list of processes with problems,
> which is usually empty, and on heavy load some processes appear in it, there's
> nothing wrong.  However, if some processes are there even without load, there
> is likely a problem.

Watchdogs are really nothing but a timeout.  The question however is
what should happen once the timeout triggers.  You could try to send
another message (basically a ping) to see if the remote side is still
alife and just this one operation is taking long.  But what if the
ping takes long as well?  At some point, you can only abort, but the
question is when this point is reached.

Looking at what I just wrote, the complexity of the problem seems to
be inverse to the number of words I can write about it without saying
anything of substance :)

> > Are the device drivers (D) provided by the operating system or the
> > user?
> 
> By the user.  The idea is that you can bring your own driver for your device,
> and don't need the system administrator to install it in order to use your
> device.  I'd expect a Hurd system to be able to do that. :-)

Yes, but the device driver framework can then not make any calls into
the drivers.  All calls must go from the driver into the framework.
This is really elementary.

> > If they are provided by the user, I don't think the driver framework should
> > make an upcall to them.
> 
> Why not?  If I bring a usb printer with me for which no driver is installed,
> and I bring a driver as well, I should be able to use it.  However, programs
> using the printer cannot accept my driver.  They will call the device driver
> framework and ask it for a list of printers.  So in order to use it, the
> printer must show up in that list.  Which means it must be plugged into the
> device driver framework.

I can't follow your description.  Obviously, there has to be a
per-user (in fact, per-terminal) device manager in the user's shell
(environment).

> > If instead all drivers are system code, and the user just activates and
> > deactivates them, I agree with your scenario.
> 
> I don't think it matters much, the scenario can also happen in that case.

I don't see that yet.

> > > Also, I'm not sure if cancellation always solves this problem.
> > 
> > It doesn't.  It can only clean up as far as the first failure in the
> > invocation chain, unless you nudge (SIGHUP?) other processes within
> > the chain.
> 
> Hmm, yes.  That may be tricky, because it is likely that the user doesn't know
> what these processes are.

Well, I can imagine a system extension that allows you to notify
multiple processes with one send operation.  This would allow you to
notify as many programs in the chain as are responsive.  However, it's
expensive (in just about every category you can think of) and I don't
know if it would really solve any problem.  It may solve some of the
problems, but my doubts are increasing.  There have been some very
good arguments from Jonathan and Christopher.

Thanks,
Marcus





reply via email to

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