[Q] DependentsArray has weakreferences

rwithers12 at attbi.com rwithers12 at attbi.com
Mon Mar 11 07:23:14 UTC 2002


Hey Diego,

I am loading ISU as we squeak.

Diego Gomez Deck <DiegoGomezDeck at ConsultAr.com> wrote:
> Rob,
> 
> >Hi Diego...
> >
> >I would like to weigh in with a few comments on this topic.  Well done
> >on putting rSt together.  I would like to help if there is anything you
> >need.  Dialect independent serialization, async messaging, reference
> >management.   more follows...
> 
> ok... that's great... just choose the topic and tell me so we don't work in 
> the same part...

Well, async messaging actually.  :)   I haven't taken *that* close of a
look but you have to be blocking for a response somewhere.  If we make
that occur at the top-most level of messaging with the object, then we
can support async messaging underneath it and we will both be happy.  I
am making good progress in understanding how a promise model of async
execution would work.  I am trying to model it closely with erights.org,
which is a pretty awesome model of async messaging.

> 
> async messaging: I don't like this feature... the mail goal in rST is 
> transparency and async-messaging do not match with Smalltalk message sends 
> (at least not match easily) .

This gave me a good laugh, because I completely agreed with you until
about 3 months ago.  Two things changed my mind.  

First is that most programming we do doesn't expect exceptions.  We have
methods like at:ifAbsent: to cover typical exceptional situations, or we
use a top-level handler, during development to catch them.  I do not
think that the exception framework is used that extensively.

Secondly, the latency of sending is such that I would rather it be
asynchronous, with the appropriate conditioning for the eventual reply,
and proceed to do other work.  This is a fundamentally different model
of conversation between objects and this difference should be made
explicitely.  For instance, in your ISU or AIM, if your peer gets
preempted (the person you are chatting with), you don't stop the other
things you were doing; you multitask without being blocked.  You may
even have an expectation that if your peer doesn't respond in a
resonable amount of time, then you will bail on the conversation.  There
is a promise of future exchange but no guarantee.


> The decision to user weak-references is in the method, not in the message 
> send... suppose that the other side is vast (I plan to port rST to 
> different Smalltalks), vast user strong-references to dependents....

mmm, good point.  If you look at the LCD of dependency mechanisms, then
you probably don't have one.  It seems it would be best to specify the
design and then implement it as you must in each dialect.  IMHO,
dependents are a weak reference of notification and not a strong
reference of use.  The world holds the view and the view holds the
model.  Other views on the model must exist in their own context,
strongly.  If no one is holding the model, then it should go away.  I
suppose this discussion could go until we are each blue in the face.  As
I see it now, a registration of dependency is a one directional
notification only.  No response is expected from the observer and the
observer has no need to expect the dependency to sustain his lifecycle.

> 
> In my opinion, you can't assume the implementation....
> 
> This "problem" (in my opinion) reflects an invalid (or not ever valid) 
> assumption on dependents mechanism and not a problem in the way that rST 
> works... of course, if Squeak will work in this way forever I must to 
> work-around this.... meanwhile I prefer to discuss if Squeak need an 
> strong-dependencies mechanism.

I agree, but good luck getting IBM to change it's event mechanism!  ;)

> 
> [snip]
> >I have recently been through a few cycles on my attempts at remote
> >objects and the most important thing I realized is that remote proxies
> >are not transparent from all aspects.  Typically it is more useful to
> >view these references as potentially broken (network/broker failures)
> >and that the context of use (the send) of a reference will dictate the
> >transformation that an argument will undergo.  (weak-reference,
> >strong-reference, copy).
> 
> Ever that you call an object the object can produce an error.... when all 
> the objects are local you have the same problem.... if you need that the 
> model continues if a view fail, you can do the same locally....

Yes, practically my exact words three months ago.  The remote observer
is one case that changes the transparency slightly.  The other is
latency and presumably more frequent network faults.  Please let me know
what you think of:  

http://www.erights.org/elib/concurrency/semi-transparent.html

This sums it up rather nicely, I think, and the implementation they use
is _sweet_.  I have the FarRef and Promise sorted out, but I need to
start looking at SturdyRefs and the tables in their distributed
framework....see: http://www.erights.org/elib/distrib/captp/4tables.html
for their GC tables for stretching remote objects, eventual sends, and
promised responses.  Very nice stuff.

cheers,
Rob



More information about the Squeak-dev mailing list