[Squeak-e] Comments on Anthony's "...Shared Smalltalk"
Robert Withers
rwithers12 at attbi.com
Wed Feb 12 08:42:54 CET 2003
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
More information about the Squeak-e
mailing list