nice(1) takes an absolute priority a

[Robert Elz]

| >	My fix was to use nice(3c) instead of the overkill of getpriority(2).
| >	Diffs follow:
| -------------
| Two things bother me about this statement.
| 
| 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.
| 
| 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.
| 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.
| 
| scott preece
| ihnp4!uiucdcs!ccvaxa!preece

Please, NO.  That is the way I used to think before I thought
about it....  Its wrong!

The compatability routines are just that, "compatability" routines.
they are not "transition" routines.

You should use the low level system calls only when you can
demonstrate a real need for them, not just because they happen
to be handy.

Think what happens when you use "setpriority" when you could have used
"nice".  Someone who takes your program to a system that doesn't
have "setpriority" (deficient as that system may be) has to either
understand your code very well, in order to deduce that you were really
just doing what "nice" would have done, or they have to emulate
"setpriority" on their system.  Since setpriority provides facilities
to alter the "niceness" of any process, group of processes, or
user's processes, that is not likely to be easy to do.

So, use the compatability routines (nice, time, alarm, ...) unless
you can demonstrate a REAL NEED.  If the extra 50us or so that it
takes to call the compatibility routine really hurts you, and
you can prove it, then go ahead, use the system call (and remember,
you can save another 50us or so at each call if you perform
the system call in line with asm's :-).  Most demonstrable uses
will be when the extra functionality is required.  This is good,
it means that a program that uses these system calls will be
visibly non-portable to obsolete/backward UNIX operating systems.

So, the nice(1) program should have been left calling nice(3)
(or nice(2), whichever), whereas renice(1) should use setpriority(2).
Nice(1) should work anywhere, renice(1) only works on 4.2
systems (to implement it on others needs something like the
gross butchery that was used to implement it on 4.1).

The only thing that bothered me about the suggested fix, was that
the test for an error was omitted.  That is not a good idea.

Robert Elz				decvax!mulga!kre

* UNIX is UNREGISTERED