[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
virtualizing IPC primitives
From: |
Neal H. Walfield |
Subject: |
virtualizing IPC primitives |
Date: |
Mon, 01 Sep 2008 12:12:12 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Thu, 28 Aug 2008 11:48:56 -0400,
Jonathan S. Shapiro wrote:
> Now the problem that you face in managing mailboxes is not quite
> analogous. Ultimately, the problem you are really dealing with is that
> you cannot use the communication substrate primitives to simulate
> themselves. There is a reductio problem.
>
> It appears to me that there are (qualitatively) only two solutions to
> this reductio:
>
> 1. Define the messaging architecture in such a way that the transient
> message body can be elided in some cases, and ensure that the
> traversal reductio can be implemented entirely within these cases.
>
> In particular, kernel-implemented objects such as cappages are
> invariably very simple, and you may be able to exploit the fact
> that all of the required operations for this object are both
> unit-time and involve very small messages.
>
> OR
>
> 2. Define the messaging queues as a *cache* backed by the respective
> applications, and design the traversal solution in such a way that
> the caches involved in the traversal are likely to converge.
When virtualizing a mailbox, how do you know when to deliver the
message vs. when the kernel should manipulate the mailbox?
Consider invoking the receive operation on a mailbox. If mailbox is a
virtualized one, the proxy needs to get the message so that it can
start receiving on the real mailbox:
server <-- client
vs.
server <--- proxy <--- client
I don't think the first solution can solve this problem. I don't
understand the second solution so I cannot comment on that yet.
Neal
- virtualizing IPC primitives,
Neal H. Walfield <=