[cap-talk] How desirable / feasible is a persistent OCAP language?
capibara at xs4all.nl
Thu Jul 17 08:36:24 CDT 2008
On Thu, July 17, 2008 14:13, Toby Murray wrote:
> On Thu, 2008-07-17 at 08:05 -0400, Jonathan S. Shapiro wrote:
>> 1. Unless the language admits some notion of concurrency (examples: Ada,
>> Java), there is a problem even talking about processes in language-based
> I had interpreted Rob's question differently as pertaining to the use of
> persistent operating system processes as a foundation on which to
> implement persistent languages, rather than the use of a process
> abstraction within a persistent language.
> Rob, can you clarify your original question here?
My apologies for the apparent ambiguity of my question.
Further thanks for the link to E persistence, I was not aware of that
facility in E, I think I will need to play around with that before I
E does its persistence.
My question was with respect to least authority at multiple abstraction
levels in combination with persistence, and whether providing facilities
to at the operating system process level allow a process private storage
for serialization or image storage, would be beneficial in allowing
systems implemented in an OCAP language to reach the level of persistence
power cycles that would be available if that same system would be running
on an OS that implemented persistence as a low level OS feature. (and that
without violating POLA by serializing to globally locatable location in a
file system). I could imagine that there could be something that would go
fundamentally wrong in consistency between multiple cooperating OS
processes , if each process serializes its relevant state, as opposed to
the OS taking care of persistence in a synchronized way, thus invalidating
one of the goals of my MinorFs project.
I hope this clarifies the context of my question.
More information about the cap-talk