implementing some of OOSC concurrency ideas [was: Re:
secure remote proxies ( was: Re: [ENH] bytecodePrimClass
andbytecodePrimEquivalentaremessage sends. Double dispatch #== )]
Rob Withers
rwithers12 at mediaone.net
Mon Jan 21 05:35:49 UTC 2002
Stephan,
Please excuse me for being so delayed in aswering this email. Between work
and getting familiar with VMMaker and SourceForge, I had put this on the
back-burner. Sorry about that.
At 07:27 PM 1/11/2002, Stephan Rudlof wrote:
<snip>
> > >But they are not identical because one is a proxy, the other not: so you
> > >need methods like #isProxy or similar at least to get this information.
> >
> > Since a proxy acts as a surrogate for the real object, clients of a proxy
> > should have no idea that they are talking to one. This is a Transparent
> > Forwarder (papers at ACM). This should include normal messages, one would
> > send to an object, like #class, #==, #size and so on. On the other hand,
> > we would want some management control, over the proxy. I think of these as
> > the location and behavioral aspects of our reference to the object.
We started this thread as a result of discussions about whether identity
should be changes in special circumstances. If we have two proxies, P1
forwards from machine L to B then to R, and P2 forwards from machine L to C
then to R, are they identical? Depending on what capabilities you are
implementing, it may be that you _do_ wnat them to be identical.
> > Of
> > course, there could be a proxy control protocol, understandable by the
> > proxy, but it would be better encapsulated by controlling the proxy through
> > a Mirror.
>
>I like this idea!
>Different 'views' of the proxy dependent on the functionality needed/wished.
>And with this idea you don't need language extensions for controlling
>visibility.
Well, I don't know. Not for basic functionality it seems, but there may be
other reasons to extend the VM and have delegation primitives.
<snip>
> > For all of these we would want control identity (Transparency), security
> > (Opaqueness), messaging (Synchronization), location (Migration), and
> > mutation (Transaction)
> >
<snip>
>Much of you have written here is *related* to what I have in mind. But the
>focus hasn't been on security, but on to ease distributed programming: some
>(slightly changed) stuff from another - personal - Mail of mine:
>
>Prenote: 2) below is somewhat outdated, since now I think - after some
>discussion with a colleague and after getting a paper (in German) from him,
>not my idea - that method wrappers are the right idea to realize
>preconditions, postconditions, invariants (he has realized it for VASt
>(alpha status, I haven't looked at it so far)). The main problem in 2) below
>is to handle OLD values in postconditions. With his method wrapper mechanism
>(not described here) this is possible.
The RB, in VW has them and I am hoping that Squeak has them as
well. MorphicWrappers certainly implements them too. That is a neat way
to proxy the behavior of an object, but I believe we want something
additional to this. State is always encapsulated and accessed through
behavior. If there are optimizations we could do, in a distributed
environment, my migrating state, then that's great, but only
optimizations. What we need to have is an ability to proxy the reference
to an object. this would include behavior that mimics the original, but
deals with the contingencies of having a different reference.
<snip>
>What about implementing some of OOSC concurrency ideas in Smalltalk?
>
>In the following I will give a very rough sketch in the spirid of OOSC.
I would have to say that the strictness of preconditions and postconditions
makes me nervous. It seems your last 5 points are roughly the
follwoing. They are all interesting steps toward concurrency. Two things
I am currently worried about are, firstly, self-sends (delegation
primitives solve this one) and return values, and secondly, deciding what
to do when the interspace communication gets wedged, do we fail or retry
every message send in the system?
1) disjoint object spaces w/ proxies
2) message wrappers or instance methods. Controlled sending
3) deadlock free concurrency
4) each space has it's own Processor
5) Polymorphism/Policied Processors for different operating environments
cheers,
Robert
PS.. am I sending HTML again??!!?!?! Please let me know.
More information about the Squeak-dev
mailing list
|