bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/25/87)
[At least *I* think they are good comments!]
--- Part one ---
How can I have a process drop the remainder of it's slice, on purpose??
If anything else is ready to run, even a lower priority task, it would
get one slice to do so before normal order was restored.
Naturally this must be upward<->downward compatible! I assume that
this is one of the reasons Switch(), Reschedule(), Dispatch() etc,
are not documented. Any ideas? Any facts?
--- Part Two ---
On a (slightly) different subject: I did something to Matt's DME editor
that worked out quite well. When a ACTIVEWINDOW message comes in it
bumps the task priority up 1. INACTIVEWINDOW restores the old set up.
Some comments on this follow:
Why not just use SetTaskPri ? This works, of course, but is not
automatic. You have to remember, then type, it.
It also does not work well for some types of programs that are sometimes
interactive, and sometimes background. Take the PC "power-user" at his
spreadsheet: While typing into a spreadsheet he does not want that
running database language compile to slow him down. Between keystrokes
there is plenty of time for that. While he is clicked into the spreadsheet,
it runs at priority 1. Now he starts a *HUGE* re-calculate, and moves on to
the wordprocessor. The situation should change... the spreadsheet should
drop to priority 0, and the wordprocessor should jump to 1. Static
priorities just don't cut it for Mr. Power-User.
While works *quite well*, a caveat does appear. If Mr. Power-User is
doing a Kermit download with his modem, and a recalculate on the
spreadsheet he is clicked into, the Kermit download will be locked out.
Ideally the system would have a provision for a special task bit
of "INTERACTIVE". A interactive task would receive the processor before
other tasks of the same true priority, *BUT* if for n consecutive slices it
hogged the processor, the other tasks could get some slices.
Mr. Power user would be treated to instant "no-load" response until he
did something that hogged too much CPU, then things would drop back to
more-or-less normal.
{ Owners of non multi-tasking PC's will laugh at this "ridiculous" scenerio.
I say to you -> get a multitasking PC, and before you know it you will
become addicted to such a smooth transition of activities. What do
you think of this, Amiga owners? }
---- More technical goop ----
There seems to be no official function to read the task priority
without first changing it. The choices are oldpri=SetTaskPri(task, 0) or
reading the ln_Pri out of the task link.
I don't trust the ACTIVEWINDOWs to come in pairs, so I read the priority at
ACTIVE time, and restore that at INACTIVE.
My DME source is old, so this is only a test installation until Matt
considers the idea.
A range of +-4 is *NOT* enough room for user tasks. Those mangy system
tasks should spread out up in the general area of 150!
----
|\ /| . Ack! (NAK, EOT, SOH)
{O o} .
( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
U Single tasking? Just stare at them for a moment, then start to laugh.