l4-hurd
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]