nice(1) takes an absolute priority a

Guy Harris guy at rlgvax.UUCP
Wed Dec 12 09:15:41 AEST 1984


> >	My fix was to use nice(3c) instead of the overkill of getpriority(2).
> >	Diffs follow:
> -------------
> Shouldn't we really be trying to avoid calls to compatibility routines?
> Just because Berkeley didn't bother to remove all their own uses of them,
> shouldn't we try not to introduce any more?  Well, I try, anyway.

If you're writing a program which should run under V7, and 4.1, and S3, and
S5, and... you should use the compatibility routines.

> In what sense is using getpriority "overkill"?  You must mean that using
> it is more work for YOU, since it's noticeably less work for the machine.

Given the number of instructions (kernel and user) executed by using the
"nice" program, I suspect the extra giftwrapping around "setpriority"
provided by the "nice" routine almost completely disappears.  It's hardly
"noticeable".

> If you use nice(3c) you add another call and then do, inside it, the
> getpriority call you could have done yourself.  And whoever reads your
> code has to try to remember whether that old nice call was relative or
> absolute.  If you just used getpriority and setpriority it would at
> least be clear exactly what you were doing.

No argument there.  I *think* all versions of "nice" after V6 add the
value given as an argument to the current "nice", but the V7 manual's
wording (the priority is "augmented" by the argument) is a bit vague
(I checked the 2.9 code, assuming it was basically the same as V7, and
it does work that way); the fact that it is that confusing indicates
that "setpriority" is nicer (no pun intended).

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy



More information about the Comp.unix.wizards mailing list