Re: setpriority() again

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

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.

Sebastian Wilhelmi                 |            här ovanför alla molnen
mailto:seppi seppi de              |     är himmlen så förunderligt blå                    |

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]