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

Rob Withers rwithers12 at attbi.com
Sat Apr 6 18:31:58 UTC 2002


Brian Keefer <mgomes21 at cox.net> wrote:
> 
> Rob Withers wrote:
> > Eventually
> > sent messages are not executed immediately.  This type of eventual
> > reference returns an object reference, as a promise, to which you can
> > eventually send additional messages, each returning a new promise
> > reference.
> > 
> > These messages, sent to the promise reference, are pending until the
> > receiver promise resolves to a real object reference (#become:), then
> > the messages are eventually forwarded to this resolved object, and in
> > turn each of their promises resolve, und so weiter.  It is remarkable to
> > me that separating the message sending from the method execution,
> > results in small sequences of pending messages queued for those promise
> > resolved objects.
> > 
> > These eventual references (objects or promises) are currenly
> > compromised, as there are a few areas in squeak where the environment
> > expects immediate values returned.
> 
> If nothing else, this LazyObject sums up my understanding of promises.
> Well, at least what I understood when I first read this post. It won't
> magically queue up messages, but it can be passed into other LazyObjects
> to stack up a flurry of last-moment resolution. 
> 
> Read LazyObject>>doesNotUnderstand: to see how to crash the VM (at least
> on linux, fresh CVS+3.2-4743, VMmaker 5.5). 
> 
> "The secret to answering quickly is to not understand the question." -
> Confucius's hairstylist.

Brian,

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.   

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.  

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. 
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? 

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

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:

Object subclass: #Future
	instanceVariableNames: 'result resultSemaphore '
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Kernel-Futures'

value
	resultSemaphore wait.
	^ result notNil
		ifTrue: ["So others can get the value"
			resultSemaphore signal.
			result value]
		ifFalse: [self signalNoResult]

value: value



	result := value.

	resultSemaphore signal.

	self 
		triggerEvent: #value:
		with: result.

exception: anException



	result := [anException signal] fixTemps.

	resultSemaphore signal.


	self 
		triggerEvent: #value:
		with: result.

I'll look into providing the identity preservation in my redirector vm.

cheers,
Rob



More information about the Squeak-dev mailing list