l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reliability of RPC services


From: Michal Suchanek
Subject: Re: Reliability of RPC services
Date: Tue, 25 Apr 2006 11:54:46 +0200

On 4/25/06, Jonathan S. Shapiro <address@hidden> wrote:
> On Tue, 2006-04-25 at 00:46 +0200, Bas Wijnen wrote:
> > So forget about all others for the moment, please.
>
> I am not interested in considering move-only capabilities. We looked at
> them several times over many years and decided that (a) they create more
> problems than they solve, (b) they don't actually solve any of the
> problems that people *think* they solve, and (c) they have negative
> performance consequences.
>

ad (c) most features that add functionality require cpu cycles to implement it

ad (b) Imagine a few  scenarios:

I get a plugin for my browser/image editor/whatever. My browser gives
a the plugin a read capability to the content it is supposed to
handle, and access to part of its window on the screen. If the plugin
does not produce what I want I can
a) kill the plugin from the browser
b) kill the browser including the plugin
Because of encapsulation I should not be able to kill the plugin
separately from outside, and I do not need anyway. The browser either
knows it has killed the plugin or is killed as well. No problem.

I get a crappy USB web camera along with a crappy driver. I load the
driver, connect the camera, and receive a few video frames.
The driver now locks up (or at least stops sending more frames). I
have no idea how the driver framework will look like but I expect two
types of connections:
a) connection between the camera driver and the USB bus driver
b) applications waiting for video frames
Since I remove the driver the driver within the driver framework (a)
should be handled. It is probably the job of the driver framework to
provide notifications and/or encapsulation for applications that want
to handle (b). Given that there are input devices, mass storage, audio
 cards, graphics cards, and other stuff this may get quite
interesting.

I am a user with a disk formatted with a horrible filesystem like
NTFS. I receive a shiny new filesystem translator that is supposed to
allow accessing the disk. So I connect the disk to my machine, and
attempt to mount it using the translator.
Now I would like to try and open a file on the disk using OpenOffice.
If it was already ported it would probably call some dialog provided
by my shell. If that cannot get response from the translator in
reasonable time I can just cancel the dialog and OpenOffice will get a
response that no file was opened.
But if OpenOffice uses a posix layer it just tries to open the file.
It should still be possible to cancel the operation in OpenOffice but
it will probably stay in progress inside the posix layer indefinitely.
Introducing any proxies or layers for whatever reason introduces such
problems.

And I do not think that timeouts or watchdogs solve this on non-realtime system.


Thanks

Michal

reply via email to

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