Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Mon, 9 Nov 1992 00:37:09 GMT
Organization: Computer Science Dept. University of Auckland

alla0008@student.tc.umn.edu () writes:

>In article <20023@acorn.co.uk> steve@acorn.co.uk (Steve "daffy" Hunt) writes:

>Out of interest, can anyone say how the Taskwindow module determines how
>much work it should do per cycle? In particular, when there's more than
>one Taskwindow task active, does each one reduce its timeslice to keep the
>co-operative cycle time about the same? Also, when a Taskwindow is idle
>(say, just sitting with a CLI prompt), it takes no CPU time - how does it
>know not to?

From the feel of it, it gives something like 20 or 25 centisecond timeslices
to the task. Also, part of it's sloth is that !Edit is Sooooo slooooow
updating the window! Using a decent taskwindow frontend with fast redraw makes
a huge difference to the actual and percieved update rates.

I think that the 'idle' you mention above is 'waiting for user input', which
means it is sitting on an OS read-line call. The TaskWindow could therefore
detect the call, and idle until it has some input to pass through to the
OS readline call, for the task to process...

---

For backgrounding tasks, the important thing is how long the timeslice of
ONE task is. If the user clicks, then an event is put on the queue, and
so the affected application WILL be called with that event on the NEXT
Wimp_Poll. Thus, the response time is directly related to how long the WIMP
has to wait before you Poll again.    ^^^^^^^^^^^^^^^^

Thus, you can have 10 tasks all taking a 15cs timeslice, but the response
time from the WIMP will ALWAYS be 15cs or less.

When you aren't generating events, the WIMP then issues a NULL poll, and the
next process gets a 15cs timeslice.

---

15cs timeslices gives approximately 6 polls per second, i.e. if you press
a key or click the mouse, the respons should be started (i.e. insert character
or start popping up a menu) within 1/6th of a second - fast enough for the user
to not notice the background load often.

If you drag a window, then ALL background activity stops while you are
doing it, so the window-drag gets 100% CPU power. Try *that* on a preemptive
system: it has to be well written before it will INSTANTLY adjust all
priorities in that manner.

This is the great advantage of cooperative: So long as everything does
cooperate (not yet the case under RISC OS) properly, the CPU time is shared
out very effectively: When little user activity is going on, all tasks have
an equal right to CPU time, and the backgrounded tasks can power along using
99% of the CPU time available. When the user clicks, control is instantly
moved to the code which processes that click, and all background activity
slows down or is suspended until the foreground task needs less CPU time.

Under RISC OS 3.10, this effect is further enhanced: Idling tasks can now
'mask out' any messages they are not interested in recieving, so many apps
will take NO processor time when idling... And if you write the 'idle-poll-
suckers' (desktop clocks, freespace, etc) to PollIdle for reasonable times
(like requesting a NULL poll once a second or once a minute instead of
as-often-as-possible), they also take minimal processor bandwidth, leaving
99% of the processor time for background tasks or foreground activity, hence
rather very muchly good excellent and brill responsiveness.
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)