Re: Resource depletion
RobS...@gmail.com
> (Heaven knows if any of the original Hermes folks ever read this group!)
>
> I've just laid hands on "Hermes, A Language for Distributed Computing"
> in the hopes of getting a little insight into how Hermes wanted to
> accomodate reliable systems based on dependably enforced interfaces
> between modules, even when the modules may have little or no mutual
> trust.
Wow. I'm amazed and somewhat gratified that someone is still
reading our book. Even more amazed that someone is still
posting about it to comp.lang.hermes!
>
> The language appears to have focused on API's and techniques to decouple
> blocking. But it says almost nothing on how two distinct processes on a
> single system will be protected from each other in the face of faulty or
> even malicious resource consumption. There's the Depletion exception,
> but if one part of the system's going to get that because of some other
> part is running wild, it seems like you've basically accepted global
> loss of functionality due to local malfunctions.
>
> Were there thoughts on this beyond what I can find in the book?
>
There were indeed thoughts on this, though they never were
implemented.
The team eventually went on to other work in distributed computing
(although
I still believe that the basic process isolation mechanism was sound).
This is, of course a problem, not only in Hermes, but in any operating
system.
The difference is that in Hermes, processes are far more fine-grained
than processes in operating systems, and Hermes has no notion, as
in operating systems, of a "userid" that can be given specific quotas.
So what are the dangerous kinds of resource consumption? Basically,
there is CPU consumption, and there is space. Other resources are
not problematic, since high level resources are implemented as
port connections, which can be managed programmatically. But
space and CPU are invisible.
CPU consumption is normally not a problem, since Hermes promises
"fair" scheduling, so even a process that goes into an infinite loop
cannot starve other processes. A bit more subtle is the fact that
a malicious Hermes process can spawn other processes, eventually
swamping the system, if "fair" scheduling were implemented in a naive
way, giving equal shares to each process.
And memory usage is potentially a problem, since processes could
allocate large amounts of memory, possibly causing other processes
that "need" it to get depletion.
The speculations on how to deal with this involved re-introducing
some notions from NIL, the predecessor of Hermes. In NIL,
processes had "owners" (a process was an uncopyable value).
Owners could kill processes -- this happened either
explicitly (via a DISCARD operation), or automatically when
the process value became uninitialized, though the ownership could
be passed to someone else (e.g., by SENDing the process
in a message). Mechanisms prevented so-called
"black holes" (processes that had no live output ports and therefore
that couldn't produce visible results), and "white holes" (unowned
processes that could flood the system with data but couldn't be
killed).
Once you had owners, you could then have pragmas by which the
creator of a process could specify an abstract resource limit
(unlike, for example, the fixed stack size limit in the beta
release of Hermes). A child process's resource limit would
come at the expense of the parent's; when it died, the resource
limit would revert to that of the parent. This meant that no
individual
process could allocate the whole Hermes run-time's memory.
We never got so far as to implement it or to check for subtler
ways that malicious users could circumvent this.
Hope this helps.
--
Rob Strom
