Re: Reliability of RPC services

[Marcus Brinkmann]

At Tue, 25 Apr 2006 09:57:22 -0600,
"Christopher Nelson" <address@hidden> wrote:
> I think that any design which expects the user to notice that something
> is wrong *and* to know how to fix it is fundamentally flawed.  Take any
> Linux, Windows, or *BSD expert, put them in front of a frozen Hurd
> system, and ask them to find the stuck process.  They will be highly
> amused.  Extending this to any normal user, and they will either unplug
> the thing, or just throw it out the window.

I agree completely.

> In order for watchdogs (a nice euphemism for timeouts) to be effective,
> the designer of the software has to be able to decide on a good metric
> for when something is taking too long.

I agree completely again.

> If the designer cannot come up
> with a good metric, then that recovery mechanism is not appropriate for
> that use case.  It is *never* appropriate to expect an end user to be
> the watchdog.

I agree partially.  It's true that the user probably can't really know
when an operation is just taking long because the machine is busy, or
because there is something botched.  However, I believe that the user
should always be in control, so if an operation is taking too long,
and the user does want to abort the operation, he should have a chance
to do so.

Still, you have a big point.  In Windows, if a program is
unresponsive, and you try to kill it, a dialog box will pop up that
says: "This program is unresponsive, do you want to forcibly remove
it?  This might lead to data loss.  End Now or Cancel."  Now the user
has two bad choices, and that sucks.

However, what's the alternative you suggest?  We are at the limit of
what we can computers make to do at this point of the discussion.  A
computer can not in all cases successfully argue about the validity of
its own operation (sounds equivalent to the halting problem to me).

Hard real-time systems define an appropriate response to this
challenge, but that response is not the most useful in all cases.

Thanks,
Marcus