[cap-talk] object-capability languages (or asynchronous message passing in general) and flooding by messages

[Matej Kosik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sandro Magi wrote:
> See the thread "Memory Accounting without Partitions" for one paper that 
> describes a solution implemented for PLT Scheme:
> 
> http://www.eros-os.org/pipermail/cap-talk/2007-June/007940.html
> 
> Sandro
> 

I have forgotten about that thread entirely. Thank you very much for
directing me to it.

The referenced article

Memory Accounting Without Partitions
http://www.cs.utah.edu/plt/publications/ismm04-wf.pdf

is relevant to my problem. There are things I like and which I do not
like. Creating a hierarchical tree of custodians (hierarchical tree of
domains in my terms) is plausible. I was thinking merely of "set of
domains" whereas they think about "hierarchically nested tree of domains".

I like very much their primitives
- - make-custodian/0
- - current-custodian/0
- - current-custodian/1
- - custodian-shutdown-all/1
- - custodian-limit-memory/3
- - custodian-require-memory/3
I consider them as very useful. They have simple semantics and seem to
be sufficiently expressive to enforce relevant security policies for the
kind of systems I have in mind.

The idea concerning process hierarchy (as opposed to hierarchy of
custodians) is another thing. It is unimaginable in Pict programming
language in the way how they use it. I also cannot agree with the way
how they assign ownership (which is tied to the artificial process
hierarchy). This is the problem I am trying to address with "domains",
related default ownership assignment rules and "donor types" that can be
used to change the default rules. They were invented exactly for the
particular situations (ways how subsystems coooperate) I observed in
Bacwater. If a message arrives in a channel, there are only two options:
- - the message will remain "owned" by the original domain that produced
it. This is the default policy.
- - or the message should be "donated" to the same domain to which a given
channel belongs to. This policy can be enforced by utilizing "donor types".
Both policies are essential in different situations.

The two terms they use:
- - producer-based accounting
- - consumer-based accounting
are unknown to me. But if it is what I think neither alone is
sufficient. That is why I introduced donor types to switch to the other
policy instead of the default one.

Otherwise plt-scheme seems to be a pretty impressive work. It is
awailable in Debian testing so I can play with it without fuss.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiy7dgACgkQL+CaXfJI/hhD+wCfcGdERej/SdHmVArYbvdhj1T/
F1wAnjLQR490huJ9mNf253Jgy+skyTvR
=crxM
-----END PGP SIGNATURE-----