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. One RPC to initiate the operation, and (optionally) a second to retrieve the result. Only a single feature is required to make this work: The server has to be able to notify (non-preemptively) the client that the result is ready (or in general: that the first operation completed). This is what the notification server design was about. To "poll" the notification server, the polling RPC must be blocking. This is the one exception, but it is contained and can be interrupted on the client side without negotiation with the notification server. Alternative notification mechanisms are also thinkable, for example kernel-supported. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
