Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mulga.OZ Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!mulga!kre From: kre@mulga.OZ (Robert Elz) Newsgroups: net.unix-wizards Subject: Re: nice(1) takes an absolute priority a Message-ID: <571@mulga.OZ> Date: Wed, 19-Dec-84 00:09:50 EST Article-I.D.: mulga.571 Posted: Wed Dec 19 00:09:50 1984 Date-Received: Sat, 15-Dec-84 02:43:38 EST References: <243@utcs.UUCP>, <47500003@ccvaxa.UUCP> Organization: Comp Sci, Melbourne Uni, Australia Lines: 61 | > 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