I like this direction of discussion.  Let us consider making the Scheduler preemptive.  It would not be that difficult to introduce time slicing to squeak.  All that is needed is a TimeSliceProcess, which could maintain a list of Process run times and bump priorities up and down based on a niceness level.   There was code for this previously posted by someone, but I don't have it on hand.   Does anybody have this code?

Isn't the real question whether we want to move squeak into a multi-threaded/-processing/-tasking environment, with all of the deadlock and starvation issues?  The current mechanism of polling works to a point, but there are some real interesting areas we could take Squeak, in these areas.  To avoid a break in continuity, it should be possible to control the activation of these mechanisms.

There seem to be some effective techniques for limiting the contention for active process times and protecting slot access.  Examples include:

- Semaphores,
- Monitors, like 'synchronised' Java and Atomic classes in ConcurrentSmalltalk,
- Linda, based on message passing and copy policy, 
- Future stacking:  Wouldn't it be possible to construct an Instruction stream, which is gated by a future completion, yet queues up message sends into the future?  I realize that this is an extreme view of coordination, and would still require a form of Monitors.  It may be possible to detect circularity between two future send chains, and throw an exception.   Crazy, huh?

My current belief, on these topics, are that a preemptive scheduler, combined with coroutines in the VM message sending stack, would open the door for some incredible avenues into multimedia.  We ought to have a safe, preemptive, reentrant environment.  Is this a reasonable goal?  If I only had the time and expertise in these areas, I would try to do it myself...but I don't  ;-)

- Rob

----- Original Message ----- 
From: "Martin McClure" <martin at hand2mouse.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Friday, September 14, 2001 8:11 PM
Subject: Re: Background tasks slow UI?


> >The RB tests take lots of time to run, so I made the SUnit TestRunner
> >run tests in the background.
> >I did this using the code -
> >
> >runTests
> >         self runWindow.
> >        [result _ self suite run.
> >        WorldState addDeferredUIMessage: [self updateWindow: result. self
> >beep]] forkAt: Processor userBackgroundPriority.
> >
> >This was simple, and worked, except that my framerate dropped from the
> >maximal ~50 to ~1, with update times hovering between 900 and 1500
> >mSecs.
> >
> >Any ideas why? I'd expect things running in the background not to affect
> >my framerate, or at least not beyond some user settable threshold (25
> >frames/sec).
> 
> How often does the test suite do a Processer yield? Since Squeak 
> Processes are not preemptive, you need to regularly yield in order 
> for the priority system to mean much.
> 
> -Martin
> 
>