Re: setpriority() again

[Tim Janik <timj gtk org>]

On Wed, 25 Feb 2004, Sebastian Wilhelmi wrote:

> Hi Tim,
>
> > I'm currently coding a suid wrapper for beast to increase
> > nicety of the sound threads. basically, things work as
> > follows:
> > 1) suidwrapper starts, does setpriority (PRIO_PROCESS, getpid(), PRIO_MIN); (i.e. nice=-20)
> > 2) drops suid-ness to euid
> > 3) suidwrapper executes beast
> > 4) beast starts BSE thread
> > 5) beast drops priority (via setpriority (PRIO_PROCESS, getpid(), 0); since
> >    i have no idea how to use g_thread_set_priority() to get exactly nice=0)
> > 6) BSE thread starts SoundSequencer thread (with G_THREAD_PRIORITY_NORMAL)
> > 7) upon user action: BSE thread starts SoundEngine thread (with G_THREAD_PRIORITY_NORMAL)
> >
> > now, upon execution of (7) i'm getting:
> >
> > (BEAST:21727): GLib-WARNING **: Priorities can only be increased by root.
> >
> > the system setup i'm using is linux-2.6.1, glibc-2.3.2, gcc-3.3, glib-2.2.3.
> >
> > the code for PID priorities in gthread.c does:
> >   priority_map[G_THREAD_PRIORITY_NORMAL] = getpriority (PRIO_PROCESS, (getpid ()));
> >   priority_map[G_THREAD_PRIORITY_LOW] = MIN (20, priority_map[G_THREAD_PRIORITY_NORMAL] + 10);
> >   priority_map[G_THREAD_PRIORITY_HIGH] = MAX (-20, priority_map[G_THREAD_PRIORITY_NORMAL] - 10);
> >   priority_map[G_THREAD_PRIORITY_URGENT] = MAX (-20, priority_map[G_THREAD_PRIORITY_NORMAL] - 15);
> > and i'm creating my threads with G_THREAD_PRIORITY_NORMAL.
> >
> > note that under NPTL, getpid() returns the same value for all the threads
> > created under 4, 5, 6 and 7. so basically what happens is:
> > - when beast starts and does g_thread_init(),
> >   priority_map[G_THREAD_PRIORITY_NORMAL] is set to -20.
> > - the BSE thread and SoundSequencer threads are started *before* (5) is
> >   being executed.
> > - the newly started threads do
> >   setpriority(getpid(),priority_map[G_THREAD_PRIORITY_NORMAL]) and succeed.
> >   i.e. they try to set the priority of *beast* to a priority they and beast
> >   already have,
> > - beast drops priority to 0, i.e. (5) is being executed
> > - the SoundEngine thread started tries to
> >   setpriority(getpid(),priority_map[G_THREAD_PRIORITY_NORMAL]), i.e. tries
> >   to set its own priority to a priority it already has (namely -20), but
> >   fails to set the *beast* priority (now 0) to -20.
> >
> > i think we should really disable the PID surrogate stuff, there's not much
> > point in renicing the same pid over and over with newer linuxes. and even
> > with older ones where this approach still works, it's pretty pointless to
> > reset priorities upon thread creation to a priority the main thread once had.
>
> Actually that wont happen if you configure on that machine. But using a
> package compiled on an older kernel/glibc combination will still show
> this odd behavior. This PID code indeed is a very crude hack and I would

the glib-2.2.3 i'm using here is a debian package, so a lot of people
have this kind of package.

> be very happy, if we could get rid of it. I implemented it to get thread
> priorities on linux, arguably our main platform. If we don't have thread
> priorities on linux, we could as well drop thread priority support from
> GLib alltogether.

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 also works on 2.4 Kernels. It might not work on 2.2. kernels, but
> that is caught by the configure.in check.
>
> > we should face it: thread priorities as provided by posix are a different
> > beast from pid niceties and thus need to be handled differently. in particular,
> > pid nicety handling has to be left up to the user, to not hinder:
> > - nice-level settings via a config dialog/file or command line option (here,
> >   users will want to specify exact nice levels)
> > - nice-level preparation via sudo wrappers, glib shouldn't interfere with that
> >   process by forcing nice-level resets
> > - ordinary idle cruncher nicing.
>
> I agree, that setting niceness values is bad, if no G_THREAD_PRIORITY_*
> is used. I'll fix it.
>
> > especially for the third scenario, it's more than a nuisance that
> > g_thread_set_priority() throws a programming warning if it fails for whatever
> > reason. e.g. trying to nice an idle cruncher to +5 via g_thread_set_priority()
> > throws a programming warning if the user started the program with nice levels >=6.
> > in a different scenario, the idle cruncher might renice itself by means of invoking
> > nice(+5) directly (since g_thread_set_priority() can't be used to accurately set
> > nice levels). in this case, it can't start anymore threads, since every new thread
> > will try to either renice itself or the main thread (NPTL) to the better original
> > nice level (-5 from the current, only allowed by root).
>
> Note however that the warning is printed once only.

that's completely irrelevant. users will still notice, --g-fatal-warnings is
still triggered, process nice levels still get messed up and by definition
of g_warning/critical/etc. the program would still be broken.

> > side note: stefan, due to getpid() returning the same pid for all threads,
> >    i'm not able to slightly lower the priority of the BSE thread compared to
> >    the SoundSequencer/SoundEngine threads.
>
> man gettid.

yeah thanks. found it meanwhile, after extensive kernel grepping.

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

---
ciaoTJ