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
