[Squeak-e] Comments on Anthony's "...Shared Smalltalk"

[Robert Withers]

Andreas, I'll just cc the list in response, since this may be 
interesting and related to our writing a squeake processor.

All'y'all, I looked into Croquet and there are in fact two schedulers.  
Of course, Andreas, is the man with the answers.  In a SqueakE vat, I 
can imagine that there could be multiple stacks pending for some event 
to occur.   Is being uninterruptible the important property of an 
event-loop?

On Wednesday, February 12, 2003, at 06:22 AM, Andreas Raab wrote:

>> The real-time scheduling of future messages is the concurrency
>> mechanism of choice, I would think.  Your scripts make it an
>> event-loop, although I suspect that the TeaProcessScheduler
>> is also an event-loop. The crucial thing about an event loop
>> is... what?  Could it be that they are uninterruptible?
>
> True for the script scheduler (within scripts), not true for the Tea
> scheduler. scripts do not interrupt each other, they have "stepping
> semantics". The tea scheduler has earliest deadline first policy which 
> means
> it _can_ interrupt another process if work with an earlier deadline is 
> being
> scheduled.

I am not sure, but I am thinking that this interruptability breaks the 
event-loop model.

>
>> TeaProcessScheduler has several structures of processes.  There is a
>> heap for timeouts (pending), a heap ordered for deadline (to occur),
>> and for lookup, but only by TeaTime, not symbols.  How does it deal
>> with symbols and pattern-matching? .. oh, the times are inserted by
>> the MessageSend, so it does have pattern-matching through sending.
>> How does it support an event system?  Well, the appropriate 
>> MessageSend
>> could occur.
>
> Like I was saying, much of this is still in flux. We are not quite 
> certain
> yet, how the earliest deadline first scheduling interacts with the 
> scripts.
> Part of this is the model of time which David develops. IOW, each 
> process
> runs "in time", and accesses state "as of" a particular time. If that 
> time
> hasn't come yet it will block (or alternatively perform an eventual
> computation which may later be aborted due to changes at "some earlier 
> point
> in time"). Much of this hasn't been implemented yet. The scheduler (as 
> of
> now) only garuantuees strict earliest deadline first scheduling.
>
>> ScriptProcessor, creates chained handlers and then suspends
>> the process (but not always).  The handlers are looked up by
>> pattern matching whenever events occur.  So you added yet another
>> event system!  ;-)
>
> For the scripts, the policy is really simple: Scripts either run to
> completion or until they wait for something to happen (this might be an
> event or a time out or a semaphore signal). Which is exactly what step
> methods do (in a generalized sense). What you see in some places (the 
> "but
> not always" part of the above) is mostly implementation detail which 
> ensures
> that certain critical notions are preserved. Such as (for example) 
> that when
> we enter a critical section *and* the process entering it can aquire 
> the
> lock immediately that it will not be suspended. This turned out to be
> critical for a number of places.
>
>> I like the semantics of it.  #signal sounds like it is a more
>> fundamental mechanism than dependencies or the multicast events;
>> like exceptions, but without all of the stack manipulation.
>> that would mean that it is an exception capability secure design.
>> :)   In fact it uses a pattern-matching mechanism, much Linda-like,
>> to reschedule scripts for execution.   So how does it deal with time
>> and time events?  Ahh, a tick list.
>
> No, this is only a little optimization to get some stuff more easily 
> out of
> it. Conceptually, this tick list doesn't matter - it's simply a 
> convenient
> way of allowing scripts to happen on each "world tick" (simulation 
> cycle,
> vat turn, you name it).


What are the entry points you use for suspending a script until an 
event occurs (#waitUntil:), creating and running a new script 
(#runScript:), triggering an event (#signalEvent:)?  I tried following 
the senders until it got to something that looked like public protocol, 
but I keep running out of senders. :)


Certainly the pattern of creating a new ProcessScheduler and defining 
the Processes that use it as non-preemptable and uninterruptable, *at 
least among each other*, may allow this minimal Squeake engine to be 
built.  My DispatchSecretary is slow and needs replacing.  Could we 
just use the ScriptProcessor for our squeake event-loop or should we 
roll our own?

cheers!
rob