[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comparing "copy" and "map/unmap"
From: |
Jonathan S. Shapiro |
Subject: |
Re: Comparing "copy" and "map/unmap" |
Date: |
Tue, 11 Oct 2005 12:42:27 -0400 |
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
- Re: Comparing "copy" and "map/unmap", (continued)
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/09
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/12
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/12
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Bas Wijnen, 2005/10/11
- Re: Comparing "copy" and "map/unmap",
Jonathan S. Shapiro <=
- Re: Comparing "copy" and "map/unmap", Marcus Brinkmann, 2005/10/11
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/11
- Asynchronous messaging (was: Comparing "copy" and "map/unmap"), Jonathan S. Shapiro, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/09
- Re: Comparing "copy" and "map/unmap", Bas Wijnen, 2005/10/10
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/09
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/14
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/15
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/17
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/18