hah@mipon3.intel.com (Hans Hansen) (01/18/88)
[ For all you d Just a thought! Have Exec alter the task priority by a given amount, with sanity check, that can be entered at any time by the user, when ever then active window or screen are changed. How I see it would work: A new command (ChActivPri) is created and takes one argument. The argument is checked for SANE input and understands negitive numbers. Numbers outside ofthe sane range are accepted but are limited to the sanity min/max values. A value of 0 would be the same as not calling the program in the first place, used to reset it. As the user changes from screen to screen the task priorities for the old screen's tasks are returned to normal and the task priorities for the now current screen's tasks are adjusted by the value of ChActivPri. Why? Well after showing off my favorite computer running all of those nifty demos, yah at the same time, and getting about 20 of them running and then TRYING to either move one or resize it... well the demos some how just run out of steam... Even more important it means that if you are running more than four programs that are CPU intensive that the current screen/window will always be be given SNAPPY service. PROBLEM: This will require improved Resource Tracking. Well you were going to implement that anyway right?!! Hans hah@inteloa -or- hah@inteloa.intel.com
louie@trantor.umd.edu (Louis A. Mamakos) (01/18/88)
Having DOS/EXEC diddle your priority according to window active/inactive? I think that we flamed this topic on this newsgroup once before. I think (and correct me if I'm wrong) the consensus was that this is a bad thing. The EXEC should not dynamically adjust the priority of tasks depending upon whether it window was active or not. (Even if it could know which task belonged to which window). Note that if an application really cares, it can do this for itself by looking for IDCMP messages telling it about ACTIVEWINDOW or not. When your window becomes active, you bump up your priority, and then drop it again when it is inactive. Note, I'm not saying this is a wonderful thing to do. In fact, if your program does this, let me know so I don't mistakenly run it on MY Amiga. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
FATQW@USU.BITNET (01/20/88)
This sounds good. However, I think, for the ChActivPri function, it should
use a RELATIVE priority. When this window gets activated, that task's
priority stays the same, but in the scheduling part of Exec, it, instead of
simply sticking it in the list where its priority is, stick it in the list
using a priority of normal priority+active priority. That way it won't
change the task's priority in any way, but you'd still have that nice feature
Also, since Intution and Exec are not *really* related, I think you should
have ChActivPri in Exec, but also, UseActivPri, also in Exec, which "activate"
a task, which adjusts its priority by the ActivPri for the task, and de-
adjusts the old active task. When a window gets activated in Intuition, it
would call UseActivPri in Exec with a pointer to the task that opened the
window.
I hope this doesn't slow down task multiplexing too much...
Bryan
Bryan Ford ///// A computer does what \\\\\
Snail: 1790 East 1400 North ///// you tell it to do, not \\\\\
Logan, UT 84321 \\\XX/// what you want it to do. \\\XX///
Email: USU@FATQW.BITNET \XXXX/ Murphy's Law Calender 1986 \XXXX/