[Squeak-e] Modules etcetera on squeak-dev
Mark Miller
markm at cs.jhu.edu
Sat Feb 26 20:11:13 CET 2005
[Sorry about the wide distribution of this message. Please direct replies to
an appropriately narrower audience -- probably
modules at lists.squeakfoundation.org .]
Cees de Groot wrote:
> I'm not sure how many subscribe here that do not subscribe or actively
> follow squeak-dev, but a team is forming to work towards a short-term
> 'modules' thingy for Squeak.
I lurk, sort-of, but the volume of traffic is overwhelming, so I don't even
read it as it goes by. Below, you mention a separate list for discussion of
modules -- modules at lists.squeakfoundation.org. I suggest that the discussion
of modules should indeed move there, if you want the attention of people too
busy to read squeak-dev.
Is the intention of this thread to fix the main problem preventing the
creation of a Squeak-E -- a capability secure variant of Squeak? By "main
problem", I mean the pervasive use of widely shared (effectively global)
namespaces and state. If so, perhaps Squeak-E is the right forum, and perhaps
we don't need yet another new list?
> Dan Ingalls leads the team, and he wants
> to implement The Simplest Thing With The Largest Impact - which means
> that he is looking at stuff like E, Vats so that modules could have
> security implications (implications in the positive sense).
The E Vat concept and the E module concept are mostly orthogonal.
Vats
Each Vat runs a singly threaded event loop -- a Vat is an island of synchrony
in a sea of asynchrony. Vats form an address-space-like disjoint partitioning
of objects, where the live references that may cross between vats may only be
"eventual references" -- references that may only carry eventually-sent
messages, so that Vats can only be asynchronously coupled to each other.
Inter-Vat references are also the only kind that may spontaneously break.
Breakage can be caused by network failure, crash, or killing a Vat -- the Vat
is thereby the unit of partial failure and resource eviction.
With these two properties, the Vat is also the largest sensible unit of
identity-preserving separable persistence, and therefore of migration.
Smalltalk's orthogonal persistence system is great, and I look forward to
having it underneath E-on-Squeak. However, this doesn't solve the separable
persistence / migration problem. Both Smalltalk and E handle the separable
persistence problem by serialization. This is where we should look for a
bridge between the E Vat concept and the E module concept.
At http://www.erights.org/data/serial/jhu-paper/index.html , I give a sketch
of a user-level serialization system for E, where this serialization system is
1) able to provide per-Vat or finer persistence, and 2) where this
serialization system is based on "un-evaluation", i.e., where the serialized
form of an object graph is an expression, and unserializing is just evaluating
this expression.
Eval & Modules
The current E module system is provided as a primitive part of E, but should
instead be built up from eval, and hopefully will be in future implementations
of E. See p8 of http://www.erights.org/talks/asian03/paradigm-revised.pdf for
a precise statement of the security properties that eval must satisfy. (That
document uses the term "loader" for the eval function.) We thereby unify
loading and unserialization -- they are both simple uses of expression
evaluation. (Oz & Oz-E unify unserialization and module loading in essentially
this way as well.)
I don't like the current E module system, and I have various thoughts about
how to change it. However, they all have in common 1) that they are built,
without cheating, on an eval with the security properties explained in the
above document, and 2) that module import may lead to shared identity, but not
shared state. What does this mean?
Suppose A and B both import name "C" from loader L. In the current E module
system, the text of C is as-if evaluated afresh each time, and so and
identities or state created by C is created separately for each of its
clients, A and B. A and B cannot come to have a communications channel to each
other merely by having shared access to the loader L, and by having asked L to
import the same module name, "C". The problem with this approach is that any
identities exported by C are not shared by A and B, preventing them from
comparing such identities in order to talk to each other about C-stuff. For
example, "x isKindOf: C" may be pointlessly picky.
I think, instead, each loader should load a given module name exactly once,
where the resulting module values are required to be DeepFrozen (transitively
immutable). This still gives us multiple instantiation of created identities,
by virtue of creating multiple first class loaders. But it separates the
relatively-safe sharing of identities from the relatively dangerous sharing of
state. In the approximation that the source of loaded modules is itself
immutable (in E-on-Java, if the classpath and its contents are immutable),
then each loader can be considered immutable. By enabling two entities to
share access to loader L, we enable them to share imported identities, but not
thereby to interact with each other.
In the Smalltalk context, where development happens primarily within a single
persistent system image, rather than by loading module files from a file
system, all these issues may look quite different. I don't yet have any clear
idea how to think about these differences.
(The BitC language has adopted the safety portion of this rule corresponding
to use of a single shared loader. See section 6.1 of
http://www.coyotos.org/docs/bitc-spec/bitc-spec.html .)
> Anyway, there's a mailing list
> (modules-subscribe at discuss.squeakfoundation.org) and a Swiki page to
> discuss this all (http://minnow.cc.gatech.edu/squeak/5608) so if you
> think you've got something to add from the E perspective, this is
> probably The Chance.
What's the relationship between http://lists.squeakfoundation.org/listinfo and
http://discuss.squeakfoundation.org/ ? I see the first lists Squeak-e but not
modules, while the latter lists modules but not Squeak-e.
When I click on the "Modules" link on http://discuss.squeakfoundation.org/ , I
get a
> Internal Server Error
>
> The server encountered an internal error or misconfiguration and was unable to
> complete your request.
>
> Please contact the server administrator, webmaster at localhost and inform them
> of the time the error occurred, and anything you might have done that may have
> caused the error.
>
> More information about this error may be available in the server error log.
> Apache/2.0.52 (Debian GNU/Linux) DAV/2 SVN/1.1.3 Server at
> discuss.squeakfoundation.org Port 80
Everyone, please remember to respond to a narrower audience. Thanks.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
More information about the Squeak-e
mailing list