[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