Re: setpriority() again

[Sebastian Wilhelmi <seppi seppi de>]

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.

Ciao,
Sebastian
-- 
Sebastian Wilhelmi                 |            här ovanför alla molnen
mailto:seppi seppi de              |     är himmlen så förunderligt blå
http://seppi.de                    |