[Squeak-e] adding eventual sending to
Croquet'sScriptProcessandScriptScheduler
Andreas Raab
andreas.raab at gmx.de
Mon Feb 17 10:50:38 CET 2003
> what am I missing?
Simplicity, efficiency and robustness. And a guy named Heisenberg ;) Try it.
It's the simplest solution since all of the critical invariants are ensured
primitively. Just think about the scheduler itself - if it were running at a
higher priority you'd need to tell it when to release the next process. But
what if 'yer aborted, terminated, killed? How could the scheduler decide if
there's already a script running? etc. You'd have to communicate too many
things explicitly that I know for given implictly by the very fact some
process is currently running.
Cheers,
- Andreas
> -----Original Message-----
> From: squeak-e-bounces at lists.squeakfoundation.org
> [mailto:squeak-e-bounces at lists.squeakfoundation.org] On
> Behalf Of Robert Withers
> Sent: Monday, February 17, 2003 6:23 AM
> To: Squeak-E - a capability-secure Squeak
> Subject: Re: [Squeak-e] adding eventual sending to
> Croquet'sScriptProcessandScriptScheduler
>
>
> Andreas,
>
> Thank you for the explanation. I was wondering a few things.
>
> why do scripts have to run in the wild?
> you provide an initial moment when the script is running to
> initialize
> itself and schedule. Is it needed?
> why not run your own scheduling script at a higher priority?
> It would
> grab any newScript requests and schedule them..resuming the suspended
> script.
>
> what am I missing?
>
> cheers,
> rob
>
>
> On Sunday, February 16, 2003, at 05:00 PM, Andreas Raab wrote:
>
> > Rob,
> >
> > The most important thing first:
> >> Ok, that works, but how is that guaranteed?
> >
> > Yes, yes, and yes. It is THE fundamental invariant. Scripts are only
> > interrupted if they block. #startScript: is non-blocking.
> Period. What
> > follows are mere details of how this is implemented ;-)
> >
> > [Note: Read up to the end of the message before replying - various
> > questions
> > might be answered further down the line]
> >
> >> 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?
> >
> > As far as the "user script" (namely: the payload of the process) is
> > concerned, #startScript: is immediate (non-blocking). It is the
> > implementation of the synchronization semantics which will
> temporarily
> > suspend the invoking user script but do so in a way that it is
> > invisible
> > from the client. The implementation essentially does:
> >
> > * script1 issues #startScript:
> > ===== system level ====
> > this is where the synchronization semantics starts. in order to
> > preserve
> > ordering of scripts the following happens:
> > * #startScript: creates a new script (script2) with a higher(!)
> > priority
> > than script1 (Processor>>initialScriptPriority)
> > * script2 preempts script1
> > * script2 schedules itself with the scheduler
> > * script2 suspends itself (in scheduler's activeList)
> > ===== user level =====
> > * script1 continues happily as if never interrupted
> > [... some time later ...]
> > * script2 gets its slot
> > ===== system level ====
> > * script2 resets its priority down(!) to regular user
> script priority
> > ===== user level ====
> > * script2 delivers payload
> >
> > To get the scheduling semantics right, I am playing with process
> > priorities.
> > As long as scripts are "out in the wild" (that is: not
> controlled by
> > the
> > script processor) they run at higher priority. This happens
> only in two
> > places: Immediately after their creation (in which case they need to
> > schedule themselves) or inside "primitive waits". In both cases the
> > priority
> > is bumped up in order to ensure that there can be only a
> single script
> > "out
> > in the wild" and that this script reschedules itself as
> quickly as it
> > can
> > with the script scheduler. [Slight OT: There *is* a chance that two
> > scripts
> > are "in the wild" if both get released after waiting on a semaphore.
> > However, in this case the user code cannot decide "which one was
> > first" so
> > ordering does not matter. For issuing #startScript:
> however, this will
> > never
> > happen, since #startScript: is only issued from scripts
> which aren't
> > "out in
> > the wild"].
> >
> > There are many, many subtleties in this regime. I went to
> great length
> > to
> > make this work "just right".
> >
> >> There may be a third script which is scheduled ahead of the
> >> currentScript.
> >
> > No. There is no way that this can happen. Literally. The scheduler
> > process
> > even runs at a lower priority than the script processes (once more:
> > priorities are our friends ;) in order to ensure that a new
> script is
> > only
> > scheduled if the current script is blocking or completed. Using
> > priorities
> > ensures this invariant primitively and avoids needless
> synchronization
> > of
> > script/processor.
> >
> >> How does the suspension of a script schedule
> >> the script for resumption?
> >
> > The script reschedules itself. When a script blocks, it
> always waits
> > on some
> > semaphore (this is the only way any process in Squeak can
> block). When
> > this
> > happens, the hooks within #beginWaitOn: and #endWaitOn:
> kick in. They
> > provide the appropriate rescheduling semantics by bumping
> the priority
> > up
> > for the wait (the script is now "in the wild" since we
> don't know when
> > it
> > will become resumed primitively) and rescheduling itself
> (and reducing
> > the
> > priority) once it wakes up again.
> >
> > One exception: Scripts inside critical sections *must* be
> run in the
> > wild.
> > The reason being that we would deadlock otherwise (I tried it ;)
> >
> >> Is there no way to schedule the
> >> new script without making it the activeScript?
> >
> > You never schedule a new script and "automatically" make it
> the active
> > script. When you schedule a script then (as the name "scheduling"
> > says) its
> > get added to the list of scripts that may be run as soon as the
> > current one
> > completes. Or do you mean "without adding it to the activeList"?!
> >
> > Cheers,
> > - Andreas
> >
> > _______________________________________________
> > Squeak-e mailing list
> > Squeak-e at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/squeak-e
> >
>
> _______________________________________________
> 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