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

[Jonathan S. Shapiro]

On Tue, 2005-10-11 at 13:46 +0200, Bas Wijnen wrote:
> On Mon, Oct 10, 2005 at 08:13:51PM -0400, Jonathan S. Shapiro wrote:
> > However, I think the case you mean is that the client wants a watchdog
> > timer.
> 
> 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.

Okay. More broadly: we are discussing situations of external preemption.
Whether it comes from ^c or from a watchdog is really not the issue.

Why do you think that this violates the IPC protocol? Either:

  1. The IPC has not started, so there is no violation, or
  2. The send has happened and we are now waiting to receive, or
  3. We are using a non-atomic (i.e. bad) IPC design.

The real challenge here is not "How do we preempt?" It is very easy to
preempt. It is easy to arrange that the client receives a code telling
it that the receive was preempted. It is also easy for the server to get
a similar code.

The real challenge here is: "How do we coordinate?" Actually, there are
*two* problems:

  1. The client has no way to know whether the server has completed the
     operation, and the server has no way to know that the client does
     not care. Some of this is a matter of design, and some of it is
     really hard.

  2. A multi-client server *MUST NOT EVER* block for a client. If the
     client does not wait to receive, the message is lost (in the
     absence of some client-arranged buffering relationship).

In EROS and KeyKOS, there are basically two solutions to this type of
problem.

  1. Most of our services are single client at a time. In most cases,
     we have lots of private copies of a service. Since each serves only
     one client, it is okay to block when the client does not accept the
     reply. This means that the client receive is restartable. Once we
     have that, the rest of the re-coordination problem must be handled
     at user level.

  2. The majority of our services are "prompt". This is a fuzzy term,
     but here is the intuition:

       A prompt service performs a bounded amount of work for any
       given operation.

       A prompt service will only call prompt services.

       A prompt service will NEVER block indefinitely.

       A prompt service will never block your request in favor of
       some other request.

     For prompt services, preemption is only appropriate when the
     service is really broken, and at that point the right thing
     to do is kill the poor service.

     One way to think of a prompt service is that it consists of
     nested atomic operations.

In practice, this tends to reduce the preemptible cases to complex,
shared services and asynchronous input. These cases are rare enough and
isolated enough that we have not had much problem with them.

shap