Re: setpriority() again

[Tim Janik <timj gtk org>]

On Wed, 25 Feb 2004, Sebastian Wilhelmi wrote:

> Hi Tim,
>
> > it doesn't do any good however. as i outlined in the examples, the pid
> > surrogate isn't usefull for increasing nor decreasing the priority. and
> > when it comes to applications doing their own nice-ing, the internal
> > nice-levek map gets messed up and the thread layer then messes up process
> > prios (might print a warning also).
> >
> > the only reason i see for keeping a priority interface at all is hoping
> > for future linux versions to support pthread priorities.
> >
> > > But we could as well fix the PID thing. We could call gettid to get the
> > > thread id and use it to renice the thread. This works well. I have
> > > attached a patch to do that and I will check it in, if no-one objects.
> >
> > the pid thing can't be fixed. please go back and reread my mail again,
> > thoroughly. ask if i didn't explain things clear enough.
>
> It could be fixed for the case, that you don't create threads with
> priorities other than G_THREAD_NORMAL and don't call
> g_thread_set_priority. In that case setpriority wouldn't be called at
> all and you're set.
>
> If priorities are used, I think a warning is better than simply ignoring
> it.
>
> As you are not using GLib thread priorities in beast, I do indeed think,
> it can be fixed for you, even after thoroughly rereading your mail.

yes, it can be fixed for beast by telling glib to stay hands-off of the
nice level.

what's with the other cases though? i.e. what would be the cases
to actually use pid based priorities:
a) a user wants the priority of his program be increased, but
   g_thread_set_priority() needs root for that => doesn't work.
b) a user wants the priority of his program/number-cruncher be lowered.
   he uses g_thread_set_priority(LOW) and things apear to work. that is,
   until he or someone else starts the program as nice -11, then it throws
   a warning because due to LOW it tries to *increase* priority to 10.
c) a program acquires nice --19 level and gradually drops nice-levels
   as/after threads are created. this is essentially the beast case, where
   gthreads nice-level map becomes invalid. as you said already, this will
   only work if priorities aren't used at all.
d) a program is always to be executed by root. here increasing/decreasing
   priorities will work as long as noone else renices the program/threads.

so essentially, it is only (d) that will work half-reliably. and honestly, that
case is so rare, that we don't need to spare the programmer his nice(-20) line.

case (b) *could* be gotten to work half-buggy by getting rid of the warning
(half-buggy, because glib will still get confused by renicing). however i've
been arguing to get rid of that warning since early 2.0 i think but you/owen
have been reluctant to remove it, effectively rendering the only remotely
usefull scenario of g_thread_set_priority() useless.
note, that the warning can *not* be circumvented by the user, since he has
no idea what glib "thinks" the current priority is, and thus has no way to
make sure he calls set_priority() with a value <= than what glib thinks
it has.

thus my votum is to scratch that API, unless linux has real priorities.

>
> Ciao,
> Sebastian

---
ciaoTJ