[Squeak-e] adding eventual sending to Croquet's ScriptProcess and ScriptScheduler

[Andreas Raab]

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
>