Re: LUTask

[skaller <skaller@...>]

On Mon, 2005-01-31 at 10:41, Mark Hamburg wrote:
> I'm actually not worried about CPU hogs. One of the nice things about
> cooperative multi-threading is that the failure mode is a CPU hog and that
> is easy to detect. The failure modes for pre-emptive multithreading are much
> harder to detect and debug.

True. However it could be hard to distinguish 'long running'
from 'infinite loop'.

For example most GUI events can be processed in a flash ..
but PAINT in particular can take a LOT of time.

> What I was concerned about was the case where a thread is politely yielding
> to other threads but has enough work to do that the run queue never empties
> out.

That is a design problem: what do you do when your CPU
cannot handle the load?

On Apollo-11 the computer shut down the altimeter
just as they LM was about to land .. :)

When the ASX opened for electronic trading it crashed
almost immediately due to overload. (ASX = Australian
Stock Exchange).

With telephone calls the answer is called 'call gapping'
which is a fancy word for 'randomly disconnect someone'.

My guess is a 'real' system will requires some pthreads
as well as the cooperative threading, but typically
a small number. The cooperative system serialises
jobs *within* a pthread.

> I was going to worry about checking a clock or having some form of
> timer-based interrupt, but it now dawns on me that a simple counter of how
> many times to resume before checking for events together with some feedback
> loop adjustments could deliver the needed behavior.

If there is a correspondence between yields and time.
For Felix there isn't -- there is a yield every
physical subroutine call, but the optimiser inlines
subroutines away .. so to force a polite yield you have
to explicitly encode one.

For a bytecode interpreter, one bytecode is a measure of
time. The problem is calling C routines from
bytecode, they can take unfairly long to complete.

> This, of course, depends on having a way to poll for events and get control
> back immediately if none are available since the condition being handled is
> one where we're prepared to process an event if there is one to process but
> don't want to hold up the system if there isn't.

For example in a GUI, you will give up 'painting' a window
if there is an event, but if not you just keep painting
until it is done. This is because the event would probably
trigger a change requiring a repaint anyhow.

> Another approach would be to have threads that wanted to yield time put
> themselves into a separate "polite" queue. When the run queue goes empty, we
> post an event to flush the "polite" queue back into the run queue if one
> isn't already posted and then go polling for events. Excessive politeness
> could, however, lead to excessive polling but that could again probably be
> treated as a feedback problem.

There are lots of architectures. I guess the idea here is not
to solve any particular problem, but to facilitate the
construction of application dependent solutions.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net