On Tue, 2005-10-11 at 18:53 +0200, Marcus Brinkmann wrote: > At Tue, 11 Oct 2005 13:46:22 +0200, > Bas Wijnen <[EMAIL PROTECTED]> wrote: > > No. It's about the following situation: > > A client performs an RPC on a server S, which may block. > > The user thinks it takes too long, and presses ctrl-c. > > Now the RPC should be aborted. However, simply cancelling the IPC would be > > a > > protocol violation. > > > > The proposed solution is to let a dedicated notification server wait for S, > > which is prepared to have it's response fail (so cancelling the IPC in the > > client is not a protocol violation). > > Note that I have decided earlier that all RPCs (except one) should be > prompt and that thus no cancellation is necessary. Cancellation is > problematic: It increases code complexity, and it requires either low > level support or some sort of RPC identification (sequence numbers, > sender ID). > > The solution is to split up potentially long-running RPCs into one to > two RPCs. ... This is what the notification server design was about.
This is very similar to an earlier design we had in EROS. It worked, but it became awkward. However: this is an underexplored area in EROS. It seems likely that we should ask the KeyKOS people how they handled this kind of thing, since they have much more experience than I do. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
