[cap-talk] 'Destroy' vs 'Sever'
Charles Landau
clandau at macslab.com
Tue Nov 27 20:03:04 EST 2007
At 4:26 PM -0800 11/27/07, Jed Donnelley wrote:
>On 11/26/2007 9:11 PM, Charles Landau wrote:
>> At 3:37 AM +0000 11/27/07, David Hopwood wrote:
>>> ...So the presence of the Sever operation implies that
>>> this composite is not defensively consistent.
>>
>> I repeat, Sever is not an operation on the object. Therefore clients
>> cannot Sever.
>
>I'm afraid I'm still a little lost with the above.
>If a "client" can't issue a Sever request, who can?
>Aren't all requesters in some sense "client"s?
>How is a Sever request authorized?
In KeyKOS/EROS/CapROS, you call a SpaceBank saying "Sever this
node/page that you created".
As has been said a few times, Sever *could* be a method on the object
itself, available to some but not all clients.
>On 11/27/2007 11:26 AM, Charles Landau wrote:
>> the purpose of Sever is only to do clone and destroy more
>> efficiently. For the many objects that don't have internal references
>> to the root, it can be very efficient.
>
>The above makes some sense to me except for the reference
>to "the root". Can you describe what "the root" is in
>the above context Charlie?
I was referring to:
At 3:37 AM +0000 11/27/07, David Hopwood wrote:
>Consider an implementation of a composite data structure, say something
>like a tree, with one visible facet representing the root. An operation
>on this facet may delegate to one of the internal objects. Suppose that
>under some circumstances, an internal object needs to call back to the
>root object in order to maintain a global invariant of the composite --
>for example to rebalance the tree.
>
>Now the root object is severed. The internal objects still have references
>to the old root, but they cannot be successfully invoked.
More information about the cap-talk
mailing list