At Tue, 25 Apr 2006 10:03:56 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > On Tue, 2006-04-25 at 13:06 +0200, Marcus Brinkmann wrote: > > However, I am _much_ more interested in discussing what the actual > > problem is we are trying to solve. It has to do with recovery... > > I agree. Also, there is something else that we all agree on: if one > mechanism can handle two problems with acceptable efficiency, it is a > mistake to introduce a second mechanism for the second problem. > > So I pose the following test case: > > Suppose C calls S, and S enters an infinite loop. How should the client > defend itself from this error? Notice that none of the "capability death > notice" ideas are helpful. > > The only mechanism that I know about that can guard against this is some > form of watchdog (which is why I am backing away somewhat from my > earlier position about watchdogs). > > If we conclude that we need watchdogs for this (or for something else), > then I suggest that kernel-supported capability death notice (any kind) > is unnecessary and should not be implemented.
There is another mechanism, which is user interaction. From the beginning, I have required a user to either kill S, or cancel C (or both). So far I have put my emphasis on "killing S", which gave me a 50:50 chance of being right ;) But I am slowly backing off and want to consider cancellation at C more seriously, because this is actually more natural. Of course, it is also possible that I am considering a non-problem, so I want to take a closer look at very specific (as opposed to abstract) test cases as well. If user interaction is not admitted to the problem, then I agree that it seems that upper bounds on wall clock time are indispensable. However, I would not rush to this solution: It seems to me that an attempt to get _that_ alternative right and proper drags you very quickly into real-time wonderland, where I am mostly ignorant, and investigating that route will probably put us off by another couple of months. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
