Re: Comparing "copy" and "map/unmap"

[Marcus Brinkmann]

At Tue, 11 Oct 2005 13:46:22 +0200,
Bas Wijnen <address@hidden> 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