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

[Robert Withers]

On Sunday, February 16, 2003, at 08:09 AM, Andreas Raab wrote:

>> But...there is an issue:
>
> Duh! Obsolete code! Sorry 'bout that - #newScript in both context and 
> symbol
> is entirely obsolete and no longer used. You need to use #startScript: 
> for
> everything, e.g.,

That does explain a couple of things.  My confusion is that I was 
looking for a symmetric invocation to #newProcess and #fork.  Part of 
the differences with scripts is that they are event driven.   It would 
be useful to see how much code we could strip from your script 
framework that would still offer the event-loop behavior.

> self startScript:
>> 	[Transcript cr;
>> 		show: 'platformName:  ';
>> 		show: ((Smalltalk startScript: #platformName)
>> waitUntil: #done;
>> result) ]

Ok, this also does the disappearing script trick.   I think it is due 
to a weakly held scriptProcess in the ScriptProcessLink.  In browsing 
the regular ProcessorScheduler and Process, the links are not weak.   
It may also reject scheduling multiple scripts of the same selector, 
but I am not sure of that.  The weakness of reference to suspended 
Scripts can be demonstrated with:

10 timesRepeat: [
	self startScript: [
		Transcript cr;
			show: 'platformName:  ';
			show: (( Smalltalk startScript: #platformName)
				waitUntil: #done;
				result) ] ]



In another mail, Andreas wrote:
>> The other issue is that I think your #startScript: may start the new
>> script before finishing the old one.
>
> It will not start evaluating the "payload" of the script (the 
> associated
> message) but it will start the associated process. This is needed in 
> order
> to preserve the order of started scripts. Here's what happens: When you
> issue a #startScript: (with no trigger) a new script process will be
> initiated. The new process will run #privateRunMsg using a +1 priority 
> of
> the default user script priority to preempt the current process. It 
> will
> then call #startScriptProcess which schedules the user script with the
> processor scheduler. It is in ScriptScheduler>>scheduleScript: that 
> this
> process is suspended. Only later, when the processor comes about this 
> script
> again, it will give it control and allow the payload message to be
> evaluated.

I have a few questions.  I don't think this is a good thing for the 
eventual event-loop.  This is interrupting the current script and I 
don't think there are any guarantees that the currentScript will be the 
first script resumed after the new script is scheduled.   Is there?  
There  may be a third script which is scheduled ahead of the 
currentScript.  How does the suspension of a script schedule the script 
for resumption?   Is there no way to schedule the new script without 
making it the activeScript?


>> I need to change that to finish the current script before
>> rescheduling any of the others.  How would you suggest we do
>> this?
>
> I don't think you need or want this. The old script will always finish
> before the new one is run, unless it blocks. For example:
>
> nil startScript:[
> 	nil startScript:[
> 		Transcript cr; show: 'inner'.
> 	].
> 	1 to: 1000000 do:[:i| i*i].
> 	Transcript cr; show: 'outer '.
> ].
>
> Will always answer "outer" before "inner". Only if you change the outer
> script to block, the inner will be run before the outer is completed.

Ok, that works, but how is that guaranteed?

I will start to strip all of the cruft I have in SqueakElib that no 
longer applies now that the ScriptScheduler is managing the queuing of 
scripts.  There is quite a bit of code I can get rid of.  I will also 
consolidate to one hierarchy of sending contexts and shift the 
semantics of entering and leaving an eventual sending regime, to the 
selectors #eventual and #immediate, unless someone has some better 
semantics to suggest.

For the moment, I would like to include the ScriptProcessor as part of 
the Elib package, so that it can be loaded in a bare-bones squeak and 
we can focus on minimizing the code.  Does this sound like a reasonable 
approach, Andreas?

cheers,
rob