[cap-talk] controversial article

[Matej Kosik]

William Pearson wrote:
> I don't know enough of the literature to be much help, but a few comments.
> 
> Lets say you have processes A, B and C. A is a spammer, B is a quick
> service which calls service C which is slow to process messages.
> 
> Can A get B killed by spamming B, B processes the messages quickly
> (freeing A's memory) and spams C. C takes a long time to clear B's
> messages, meaning B goes over its quota. Or do I have something wrong
> with the system works?

This is an excellent example.

The answer is "Domain A (not B) will be killed." It is determined by the
whole set of reduction rules. The article picks only few of them and
intends only to give a glimpse. The complete set of reduction rules is
stated in the documentation of the Sahara compiler:

http://altair.sk/mediawiki/upload/6/69/Sahara.pdf

in Section 10.4.8 which is boring but it was necessary for me to be able
to complete the compiler.

One of the reduction rules that is relevant to the answer:

   "Domain A (not B) will be killed."

which is not stated in the article is AOut-R. I have attached the
original Turner's version (file AOut-R.png) and the augmented version
(file AOut-R'.png). The augmented version states that the continuation
of the resumed reader will be owned (in case of *regular send*
(not *donating send* operation) by the sender.

So, applied to your scenario, if some particle within domain A sends a
message to a channel owned by B and later some particle from B will
consume that message, the continuation will be owned by A---i.e. by the
client that invoked that service. So if that continuation in turns
requests services from C then that message (until it is consumed) will
be also owned by A. If A exceeds its memory quota, it will be killed.
Hence the answer.

I think that the current formulation of reduction rules is plausible
(whatever viewpoint I take) although I am ready to change them if it
will be revealed that ownership is assigned in an unfair way.

> 
> It seems to me that there are quite a few more issues in trying to
> create defensively correct system over those you have identified.
> Examples include malicious software that causes a lot of page swaps or
> garbage collection due to the way it uses memory. Basically anything
> that a program can do to cause the system to use more processing power
> or memory than it would otherwise do.

I am concerned about this too. I have split the problem to two subproblems:
- how to address memory-problems
- how to address CPU-problems
I am going to play with the second subproblem this summer. The scheduler
of the runtime (which determines which runnable processes to resume,
ideally with O(1) complexity like the original scheduler) must be
replaced. The scheduler can also proportionally penalize domains with
respect to garbage they generate.

Note that the first subproblem had to be solved because cancer- and
spammer-like threats lead to "game over". The CPU-threats only degrade
the response of the system but even now the progress of all parts of the
system is guaranteed [Pierce&Turner].
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AOut-R.png
Type: image/png
Size: 14593 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20090702/8aeefbcd/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AOut-R'.png
Type: image/png
Size: 17546 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20090702/8aeefbcd/attachment-0003.png