Object pointers (+ a de-ENH, and a crash)

Brian Keefer mgomes21 at cox.net
Fri Apr 12 04:33:39 UTC 2002


> Sorry for the late reply.  I returned from Europe, this week, to find I
> had Cable modem issues.   I posted an implementation of what I discuss
> above at http://minnow.cc.gatech.edu/squeak/2410.

My only excuse is that it took me this long to think about the issue. I
need to give my eyes some time to uncross.

> You called this object of yours, silly, in the sense that it was
> changing state underneath you.  Thanks to your work, mine doesn't change
> identity now, so I will try to claim that if it's identity doesn't
> change, then the processing of messages to it should be predictable to
> users.

I consider it silly because I am only following my aesthetic sense in
making it. I have no practical project to actually use and test it in.
Experiencewise, I still believe that new object instances are delivered by
a stork ;) .

> In your example, you have a promise to a string, and you send it string
> protocol messages.  To me, it seems as if this object were never there.

That is an awful example that I gave. I would have been better off
bogo-sorting something, and demonstrating that the pain is postponed.

> Is this what you think silly about it?   If it's predictable in this
> synchronous setting, it should be in an asynchronously sending
> environment and that is where the promise can start working for us.  Do
> you think interaction with asynchronous references is intuitive?

By unpredictable, you mean that the message chain is already halfway
worked through when the promise is called upon for a final answer, right?
I have no opinion on async refs.

> Having thought about the question some more..  #becomeForward: must be
> slower than my #primSwitchRedirector:toContext:, since it has to do a
> GC.

becomeForward: may not be quite as catastrophic as you think. I started a
small thread about (almost) this, "Why can't I do (aNonSmallInteger
becomeFoward: aSmallInteger)". According to Tim Rowledge, identity swap is
done in a trickier, less memory thrashing method than a full GC. My
current belief is that these "fowarding blocks" that ObjectMemory mentions
provide an extra indirection until the next GC fixes things up. 

> My code uses a MessageRedirectorProxy, which defers all message sends to
> it's context object.  The promise context will mutate into a near or
> broken context when the promise is resolved.  At this point, I believe
> your object could fit here nicely.  For it to block until asynchronously
> resolving the promise, you could have the block call a monitor, which
> could block until the task which was promised, resolves.  This could be
> done by a Future object (which is called a Promise in VW).  My
> implementation looks like:

Feel free to take anything you find useful, it will probably be purged by
the next version.

The new and EEMPROOVED LazyObject now lives at
http://minnow.cc.gatech.edu/squeak/2421. This time it actually supports
(gasp) explicit message queueing. I recently found that the coolest
message to enqueue is #in:. 


"You know how to whistle, don't you? Just put your lips together and
blow."
- MS tech support in "Patlabor"



More information about the Squeak-dev mailing list