At Tue, 25 Apr 2006 22:46:17 +0200, Bas Wijnen <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
