jim@baroque.Stanford.EDU (James Helman) (06/11/90)
Even though our IRISes' primary purpose in life is 3-D graphics, they get used quite a bit for numerical computatations because they're much faster than anything else we have (there's a Conves in the building, but it's not ours). Also, our diehard FORTRAN users can't do anything our Suns anymore because we never got around to ordering Sun's FORTRAN compiler after Sun uncerimoniously unbundled it. But the numeric computation is basically a parasitic use. We'd like to be able to suspend computational jobs when running graphics. Nicing isn't enough, especially if the other jobs are pounding I/O. Under BSD, one could just "kill -STOP" a process and then "kill -CONT" it later. But under IRIX, if the process is no longer connected to a tty, "kill -STOP" causes the process to exit. Is there any way to suspend a process under IRIX? Jim Helman Department of Applied Physics 6 Trillium Lane Stanford University San Carlos, CA 94070 (jim@thrush.stanford.edu) (415) 723-9127
doelz@urz.unibas.ch (06/11/90)
In article <JIM.90Jun10225458@baroque.Stanford.EDU>, jim@baroque.Stanford.EDU (James Helman) writes: > > But the numeric computation is basically a parasitic use. We'd like > to be able to suspend computational jobs when running graphics. > Nicing isn't enough, especially if the other jobs are pounding I/O. > If you're root, do a # npri -h250 -p<pid> and the process will literally die but execute always if there is nothing else to do. Because you presumably don't want to have anyone root priv, set up a cron script which greps the cpu choppers from the process table every hour. We did that, and since that time there is happy graphics computing while at least two steady number crunchers are powering at night. > > Is there any way to suspend a process under IRIX? Use the call blockproc(2). There, you'll find the description to block a process. The call can be issued from both fortran and c . I don't think it to be great because you always need to remember to unblock the process again. Therefore, I use the schedctl(2) call as described above, which uses the following priorities (taken from /usr/include/sys/schedctl.h) : /* possible non-degrading priorities */ /* these priorities are higher than ALL normal user process priorities */ #define NDPHIMAX 30 #define NDPHIMIN 39 /* these priorities overlap normal user process priorities */ #define NDPNORMMAX 40 #define NDPNORMMIN 127 /* these priorities are below ALL normal user process priorities */ #define NDPLOMAX 128 #define NDPLOMIN 254 .. take care not to use PHI values, you'll kill your system... Good luck, Reinhard ************************************************************************ Dr. Reinhard Doelz * EAN doelz@urz.unibas.ch Biocomputing * DECNET 48130::doelz Biozentrum der Universitaet * X25 psi%46211142::embnet Klingelbergstrasse 70 * FAX x41 61 256760 CH 4056 Basel * TEL x41 61 253880 ext 888 ************************************************************************ PS: If you get tired of all that, run dbx on the process you want to stop using the following command in the 'console' window: # dbx -p <pid> >& /dev/null & and you will have the process supended. If you log out the window manager, the console window dies, and therefore, the process is released again.
slevy@poincare.geom.umn.edu (Stuart Levy) (06/12/90)
I'd like to know why this happens, too -- why SIGSTOPping a disconnected
process causes it to die. It seems a reasonable thing to do, and works on
other systems which support SIGSTOP. Could it be that /etc/init, finding that
its wait() call returns mentioning a process that it hadn't started,
goes and murders the innocent process? If so, doesn't that seem like a
bug in init? If not, what on earth is happening here?
Stuart Levy, Geometry Group, University of Minnesota
slevy@geom.umn.edu