nice(1) takes an absolute priority a

Geoff Collyer geoff at utcs.UUCP
Wed Dec 12 10:04:06 AEST 1984


Scott Preece wrote in reply to my bug report:

	>	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.

I'm interested in keeping programs compatible with non-4.2BSD UNIXes.
Just because Berkeley isn't and puts nasty words in the manual pages
is not reason to stop using the compatible interfaces.

	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.

I refer to the unnecessary complexity of the set/getpriority interface for
doing the simple task of changing the nice of the current priority.
setpriority has the ability to request of change of priority for processes
selected by process group, user id or process id and this is sufficiently
confusing that the person who changed nice(1) to use setpriority got it wrong.

And what's wrong with preferring the simpler interface?
Incidentally, setpriority is not significantly cheaper than nice, for this job.
One extra function call, which hides the baroque complexity of getpriority
and setpriority, is certainly worth the cost.

I find the use of nice far clearer than the combination of getpriority
and setpriority.  Anyone who is unfamiliar with nice is unlikely to be
capable of writing portable code.  People who limit themselves to knowledge
of 4.2BSD are severely restricting the portability of any code they write.
N.B. to flamers: this doesn't mean that one must learn the rococo intricacies
of System V; simple understanding of v7 will suffice.



More information about the Comp.unix.wizards mailing list