[Squeak-e] adding eventual sending to Croquet's ScriptProcess and
ScriptScheduler
Andreas Raab
andreas.raab at gmx.de
Sat Feb 15 16:41:59 CET 2003
Rob,
> What do you think would be the best way to activate the resolver?
Remember the resolver in the process' properties (cheap way to experiment
with it - later we may want this to be an iVar) and then use
#stopScriptProcess: to notify the resolver (if there is one). Seems like the
simplest solution to me. One more thing to keep in mind though:
#stopScriptProcess: is also invoked from #terminate and you'll probably need
something else to notify the resolver that this promise was broken.
Cheers,
- Andreas
> -----Original Message-----
> From: squeak-e-bounces at lists.squeakfoundation.org
> [mailto:squeak-e-bounces at lists.squeakfoundation.org] On
> Behalf Of Withers, Robert
> Sent: Friday, February 14, 2003 6:30 PM
> To: 'Squeak-E - a capability-secure Squeak'
> Subject: RE: [Squeak-e] adding eventual sending to Croquet's
> ScriptProcess and ScriptScheduler
>
>
> Andreas, I said:
>
> > -----Original Message-----
> > From: Withers, Robert [mailto:rwithers at quallaby.com]
>
> > I am curious about your use the ivar #myQueue in the
> ScriptProcess. I
> > really like that your ScriptProcess will compute a value, and
> > that that
> > value is the 'result' of the process. That's a very
> standard view of
> > computations. Isn't it a functional view? A better approach
> > for supporting
> > eventual sending may be to have a subclass of ScriptProcess
> > which holds the
> > continuation to the invocation site.
>
> Actually, I am now thinking that a subclass may not be needed, since
> ScriptProcess already holds onto the invoking message
> (AsyncScriptMessageSend to be replaced by
> EventualScriptMessageSend for
> eventual sending) and the owner, which is the same object.
> There are also
> the ivars #myHandler and #myEventMap.
>
> In the following method, called when the Process returns from
> the last stack
> frame, there are three different mechanisms that we could hook into to
> activate the resolver.
>
> ScriptProcess>>#stopScriptProcess: result
> ...
> owner ifNotNil:[owner scriptStopped: self].
> myHandler ifNotNil:[myHandler releaseTo: nil].
> myEventMap ifNotNil:[self signal: #done with: resultObj].
>
> - owner is the ScriptMessageSend, so an implementation of
> #scriptStopped: in
> the EventualScriptMessageSend, could activate the resolver.
>
> - myHandler is set when sending #observe: and it is an EventObserver.
> Currently this only looks to be used by the #waitUntil
> protocols and it
> blocks on a semaphore. I suppose that a special observer
> could be created
> that holds the resolver.
>
> - myEventMap holds event registrations. These can be set at
> a low-level
> with #on:notify: or at a higher level by startScript:when:.
> So after the
> EventualScriptMessageSend is converted to a ScriptProcess, a
> registration of
> the following could wake up the resolver
> proc on: #done notify: (#resolve: asAsyncScriptMessageIn: self
> resolver arguments: #())
>
>
> What do you think would be the best way to activate the resolver?
>
> cheers,
> rob
> _______________________________________________
> Squeak-e mailing list
> Squeak-e at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeak-e
>
More information about the Squeak-e
mailing list