dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/20/86)
That IDIOT *!#@$% RUN command sets the process priority of the process it's running to -5!!!! Meaning, that if I have a compile running in the foreground, and an ED in the background, the compile gets priority over the ED. So, when the compile stops going to disk and goes into it's "do nasty calculations all in memory", the editor stops working until the compile is done. My question is..... how can we fix it. More importantly, I'm asking the Amiga people to fix it in upcomming versions ... the RUN command should set the priority to ZERO... and not make any assumptions about the process it's running (the current assumption being that any process in the background is not as important as one in the foreground). <sigh> -Matt
page@ulowell.UUCP (Bob Page) (04/24/86)
Recently, dillon@CORY.BERKELEY.EDU (Matt Dillon) wrote: > That IDIOT *!#@$% RUN command sets the process priority of the >process it's running to -5!!!! That seems pretty logical to me. If I say 'I want this in the background', to me it means 'do it, no hurry.' FYI, the c-shell works the same way when you "&" something. > Meaning, that if I have a compile running in the foreground, and an > ED in the background, the compile gets priority over the ED. Maybe you should rethink your application! Why not edit in the foreground and compile in the background? ..Bob -- UUCP: wanginst!ulowell!page Bob Page ARPA: page@ulowell.CSNET U of Lowell CS Dept VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA
sgt@alice.UucP (Steve Tell) (04/25/86)
>From: dillon@CORY.BERKELEY.EDU (Matt Dillon) > That IDIOT *!#@$% RUN command sets the process priority of the >process it's running to -5!!!! Meaning, that if I have a compile running in >the foreground, and an ED in the background, the compile gets priority over >the ED. So, when the compile stops going to disk and goes into it's "do nasty >calculations all in memory", the editor stops working until the compile is >done. > My question is..... how can we fix it. More importantly, I'm asking >the Amiga people to fix it in upcomming versions ... the RUN command should >set the priority to ZERO... and not make any assumptions about the process >it's running (the current assumption being that any process in the background >is not as important as one in the foreground). It seems to me that since the scheduler handles priorities this way that it severly limits the usefulness of having priorities at all. For most of the situations I would use, there would seem to be essentialy only low, medium, and high, with little use for more levels. A better fix would be to alter the scheduler so that low-priority processes still get some time. Then, you could pick the priorities so that the compiler was fast enough to satisfy you, and let the editor crawl along, or whatever. When there is a big difference in the priority numbers, Nearly all of the time could go the high-priority one like it does now, so you'd have the best of both worlds. If the fix Matt sugests is implemented, lets keep the old RUN and rename it NICE.
cc1@ucla-cs.ARPA (Michael Gersten) (04/30/86)
There is one very major bug with run setting a lower priority. On unix, this is no problem as A. Background jobs by default get no terminal input B. Unix has a scheduler that adjusts priorities. BOTH of these assumptions FAIL on the amiga. I recently had to change my startup-script to 'run loadwb' just so that the 'run execute' command i have in there starts up competitive jobs. IF you can get newcli to take a command script THEN I will agree that run should set a lower priority. BUT THERE IS NO WAY (Please, please, correct me if I'm wrong!!!) to start a second interactive program without either the workbench or the run command. NEWCLI does not work--I want a program (specifically, clock, notepad, and a newcli with a custom window) to be available at the standard priority with no other window on screen. Unfortunatly, the original window refuses to go away if there is any 'run command' task still active. Michael Gersten -- Views expressed here may not be those of the Computer Club, UCLA, or anyone.
acs@amdahl.UUCP (Tony Sumrall) (04/30/86)
Isn't there a pgm to set the priority of a running task? If there isn't
it seems to me that C-A screwed up by not providing it (not a big screw-up,
just a little one). Aside from that, shouldn't the RUN cmd have an
option which allows the user to specify the priority?
Just a thought.
--
Tony Sumrall ...!{ihnp4,hplabs,seismo,sun}!amdahl!acs
[ Opinions expressed herein are the author's and should not be construed
to reflect the views of Amdahl Corp. ]cjp@vax135.UUCP (Charles Poirier) (04/30/86)
In article <294@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >Recently, dillon@CORY.BERKELEY.EDU (Matt Dillon) wrote: >> That IDIOT *!#@$% RUN command sets the process priority of the >>process it's running to -5!!!! > >That seems pretty logical to me. If I say 'I want this in the >background', to me it means 'do it, no hurry.' But to me, it means 'do it as fast as you can, meanwhile I'll kill some time doing something else.' Really, the process priority should be an optional parameter to RUN, defaulting to 0. Charles Poirier
perry@atux01.UUCP (P. Kivolowitz) (05/10/86)
Sorry about being late with this comment, but I was unable to post news for a while. The problem is actually due to the AMIGA scheduler. It is not a true round robbin with pre-emption. Without pre-emption, a process with a lower priority may never run given the presence of a compute bound process with a higher priority. The RUN command should not, however, change a processes priority. The analogy with csh reducing the priority of background tasks is not a valid one. The AMIGA paradigm is that of multiple concurrent sessions not one session with some jobs running in the background. Perry S. Kivolowitz