[Squeak-e] adding eventual sending to Croquet's ScriptProcess
andScriptScheduler
Robert Withers
rwithers12 at attbi.com
Sun Feb 16 13:13:40 CET 2003
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
More information about the Squeak-e
mailing list