[cap-talk] How desirable / feasible is a persistent OCAP language?

Jonathan S. Shapiro shap at eros-os.com
Thu Jul 17 07:05:02 CDT 2008


On Thu, 2008-07-17 at 12:33 +0200, Rob Meijer wrote:
> I personally feel that real persistent processes, (especially when using
> an OCAP language to create the code for these processes) would greatly
> help in reducing the complexity of least authority design, but given the
> fact that this subject to my knowledge has not been more than slightly
> touched on this list, I have no way of knowing if this personal stand on
> is one that has a general consensus, is by general consensus just
> considered clueless, or has both lots of people agreeing and disagreeing.

I don't think that persistent processes is exactly what we want. I think
what we want is something more like a persistent C-VAT. The "C" stands
for "concurrent". Let me try to explain what the heck I am talking about
here.

Observations first:

1. Unless the language admits some notion of concurrency (examples: Ada,
Java), there is a problem even talking about processes in language-based
systems. Absent a concurrency model, the process abstraction isn't
really connected to the language abstraction in a readily specifiable
way, so talking about the meaning of process persistence is dicey.

2. When concurrency *is* admitted into the language, the marginal cost
of implementing multiple threads in the runtime layer is negligable.
Conversely, the marginal overhead of using such an "augmented" language
runtime to implement a single thread of control can be ignored.

3. In my view, the primary distinction between multiple processes and
multiple threads is that multiple processes do not share mutable state.
As a matter of implementation, I would actually prefer that they not
share a heap, but on reflection I can live with the "no shared mutable
state" restriction. What I am calling here a "process" is approximately
what .NET CLR calls a "domain".


The point that I am leading up to is this:

  1. A process (NOT a thread of control) is certainly the *least* unit
     that can sensibly be persisted, but

  2. It is useful to be able to define persistence domains that are
     larger than a single process.

So to answer your original question:

I believe that C-VAT persistence is extremely useful. Further, I think
that the E sturdyref/brokenref/disconnectedref concept is a great way to
think about re-establishing connectivity across C-VATs.

MarkM may argue about the desirability of the "C" in C-VAT. The E VAT
design puts persistence and schedulable units at a common domain
boundary. That is obviously a feasible design and probably even a good
one. The point I'm trying to make with the C-VAT distinction is that it
isn't the *only* feasible arrangement of concurrency and persistence
domain boundaries. It does have the very great merit of being simple.


> Next to the desirability question, a second question might be just as
> important, how feasible would it be to make one (or more) of the current
> OCAP languages into a persistent language...

Umm. Have you looked at the E persistence mechanisms?


shap



More information about the cap-talk mailing list