bob@acornrc.UUCP (Bob Weissman) (12/11/86)
I notice that having defined NICENESS=4 in defs.h, that rnews ends up
running at niceness=8. compress and unbatch run properly at niceness=4.
Therefore I suspect that nice() is getting called twice, once by a
parent process and once by a child?
My online manual (4.2bsd) suggests that nice() is obsolete in favor
of setpriority(), which doesn't have the "feature" that its argument
is added to the previous niceness.
--
Bob Weissman
UUCP: ...!{ ames | decwrl | oliveb }!acornrc!bob
ARPA: "acornrc!bob"@DECWRL.DEC.COMmangler@cit-vax.Caltech.Edu (System Mangler) (12/12/86)
In article <215@acornrc.UUCP>, bob@acornrc.UUCP (Bob Weissman) writes: > I notice that having defined NICENESS=4 in defs.h, that rnews ends up > running at niceness=8. compress and unbatch run properly at niceness=4. Scenario: uux hands a compressed batch to rnews. Rnews nices itself by NICENESS, sees the "#", runs unbatch, which sees "#! cunbatch" and runs cunbatch, which uncompresses the batch and feeds it to rnews. Rnews nices itself by a second NICENESS, sees a '#', runs unbatch, which sees "#! rnews" and runs rnews. This nices itself by a third NICENESS, and installs the article. We have NICENESS set to 6. Fortunately we get very little compressed news, favoring nntp instead. Nntpd runs at nice 4, so that nntp news reception runs at nice 10 as we intend. The fix is obvious: don't invoke nice() until after checkbatch(). > My online manual (4.2bsd) suggests that nice() is obsolete in favor > of setpriority(), which doesn't have the "feature" that its argument > is added to the previous niceness. Uh, sure, ever write a (Bourne-shell) script that does "nice -4" and notice that the script bombs if your nice value is already more than 4? That comes about because /bin/nice was converted to use setpriority... In 4.3bsd, /bin/nice has been restored to the 4.1bsd functionality, though sadly the simple, working 4.1bsd code was not used... Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck