I just realized that I was talking about the use of these classes in the
DispatchQueue context.  These don't drain, they just loop on a conditional
and evaluate the action block.  There is also a delay in them, and that is
another knob for controlling the rate.

We really ought to have a PriorityJugglerProcess to give us time slicing.

sorry for the mix up,
- Rob

----- Original Message -----
From: "Rob Withers" <rwithers12 at mediaone.net>
To: "Squeak ML" <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, August 27, 2001 2:23 AM
Subject: [Enh] Tasks framework


> This is a lightweight Task framework, that includes a background Task and
a
> MorphicTask, which probably does what other code (#addDeferredUIMessage:)
> does, but I didn't change it yet.
>
> The Task class forks a pocess, which performs an actionBlock while the
> scheduleBlock returns true.  You can control the rate at which it drains,
> although it is probably a good idea to drain as fast as you can.  You can
> control the priority as well.
>
> The MorphicTask registers into the stepping framework.  You can also
control
> the rate of draining in this class.   This is a nicer feature, as it
allows
> you to pump a lot of messages into the queue and still have a responsive
UI
> while the messages are drained.
>
> One thing I do, with the async framework, is register an async proxy as
> Transcript, which generates async messages, pumped with a MorphicTask.
Now
> all code in the system that prints to the Transcript is threadsafe and
> asynchronous.  It's nice.
>
> - Rob
>