[Squeak-e] adding eventual sending toCroquet'sScriptProcessandScriptScheduler

Andreas Raab andreas.raab at gmx.de
Tue Feb 18 00:12:51 CET 2003


> I am not sure why you couldn't attach a state machine to the 
> process so that it would do the right thing when a scheduler
> Process asked it to reschedule itself.

You could. It would simply be a different approach, one which requires much
more care in a variety of places. For example, consider an error which
throws up a debugger. You would have to take much care to handle this case
correctly. Even worse, external interrupts (such as user interrupts) can
interfere with your careful scheduling semantics. In every single case where
the scheduler isn't explicitly notified your system will be entirely hosed
with no way out. Because debugging this stuff is incredibly hard and making
mistakes is easy, I wanted to have a way that is simply fault-tolerant in
the vast majority of cases. After thinking about all the associated issues
it seemed to me that making it so that the system "runs by default" is the
best choice to make.

> There looks to be quite a bit of state in ScriptProcess
> already.  Since all scripts are at the same priority, you 
> are allowed to do this, right? 

Yes. And because of the scheduler semantics. This ensures that as long as
you stay in the "script universe" everything works out right.

> If they could have different priorities, then you could
> be interrupted.

But they don't. "Process priorities" are not part of the scripting universe.

> What is the low-priority scheduler Process?  Is it the ticker?

Yes, it's essentially the process which invokes #runActiveScripts and
controls the "life line" of the system. In E terms it's the process which
controls the VAT turn (I think).

> I am currently more concerned with the lost scripts that I am 
> experiencing.  I opened a Process Browser and sure enough, there were 
> all my Scripts waiting on Semaphores.  I must have opened up a hole 
> somewhere by a) submitting multiple scripts (in a loop) and/or b) not 
> signaling a semaphore (or calling some method which does this 
> under the covers).

Hard to tell. One note though: You should not assume things to work
correctly from outside the scripting universe. IOW, when you do something
that requires "script scheduling semantics" you cannot do this from a
regular workspace *unless* you wrap it into a startScript: first. I have not
provided the means to drive all of Morphic from the scripting regime.

> Andreas,  I wrote about some issues I was having with dropped
> or locked scripts.  I need to debug this situation.   How do
> I turn on traceEvents?

ScriptEventTracer trace: #eventName in: eventSignaler.

This will hand you an event tracer which is notified about *all* of the
events and messages which directly or indirectly occur in response to the
initial event (that is even nested signals from scripts and their responses
will be reported). This can be a tree of events/messages (if there are
multiple handlers of the event) and it can take forever (quite literally so
if one of the scripts blocks forever). You can get the "current" (e.g.,
partial) list of responses by looking at its log (which contains

Note: Part of the interface is missing (I just noticed this). The event
tracer doesn't expose an interface for querying about its results.

Note^2: If you use the tracer and read out its contents you should do this
from scripts - it does not provide any locks (the scripting universe has no
need for it) and unexpectedly preempting it might turn out problematic.

  - Andreas

More information about the Squeak-e mailing list