At Tue, 14 Jun 2005 18:22:54 +0200, Bernhard Kauer kauer@os.inf.tu-dresden.de wrote:
We use the following copy()-example in our discussion:
A file server implements file-objects and distributes capabilities of them. It offers, for an atomic copy of a block from one file to another, a copy(src, dst) operation. Since both parameters are given by an client in one call, we have the multi-reference problem.
This example would have the same problem, but I don't think that anybody would design a filesystem that way. Just as a side note.
Are there other examples that cause problems?
How many examples do you want before the mail gets too long? I have given two examples in my original mail. The first example is similar to yours above. The second example was the reference counter, which is the more important one! The above example you give is just the basic example, while the reference counter shows the bigger problem.
Beside the need for a cmp() we found in the discussion that this operation needs to be limited.
I offered a way to limit my map_lookup() functionality.
A transparent interpose of different endpoints with a single one is otherwise not possible.
This just shows that reintroducing global IDs through the backdoor is ill-advised. My recursive lookup approach has the desired locality properties.
Bounding this "cmp()-right" to the receive right of an endpoint seems feasible.
I explained why it is not sufficient in my earlier mails. Specifically, I showed how reference counting would not be possible, or introduce a heavy cost: Object management in a trusted service, which requires one additional RPC per message just to identify the objects, including the primary one on which the message was invoked.
It is important for us that reference counting does not impose further costs on the RPC path. I hope it is clear why.
So in summary I can say, we heavily think about, whether we extend our model with a cmp() operation...
I hope you don't limit the analysis to the cmp operation at this early stage.
Thanks, Marcus