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