[cap-talk] Reducing Ambient user authority in a Type Safe/Memory Safe OS.

[David-Sarah Hopwood]

Bill Frantz wrote:
> david-sarah at jacaranda.org (David-Sarah Hopwood) on Saturday, January 2, 2010 wrote:
> 
>> Not really. You need a way to account for resources (including memory
>> segments) held by processes and not linked into the filesystem, anyway.
> 
> Agreed.
> 
>> So files held open by a process can just be accounted to that process.
>> Files linked from multiple places should be accounted to all of those
>> places (each for the full size).
> 
> How you account for shared resources is a religious issue, and I'm an
> agnostic.
> 
> IMHO, it is good to allow many users to share the cost of an expensive
> resource, possibly making something that would otherwise be too expensive
> for one affordable for all.

It is indeed a religious issue, but my particular sect does have some
concrete rationale:

If a subject has a strong reference to an object, then it's causing the
object to be retained. If it were not charged the full price, then
other subjects' actions could cause the price it is paying to increase
unexpectedly.

If a subject has a weak reference to an object, then it's not causing the
object to be retained, and therefore needn't be charged. Of course this
requires the subject to handle errors if the reference breaks.

Given this policy, it's possible to implement cost-sharing references as
a higher-level abstraction: a trusted broker holds a strong reference to
an object, then charges for the weak references that it gives out. The
broker's contracts with its clients can specify conditions under which it
guarantees that the weak references will not break, for as long as the
broker remains in existence.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20100102/acb02a35/attachment.bin