Re: [PATCH] make setpriority POSIX compliant; introduce PRIO_THREADextension

[Chris Friesen]

Michael Kerrisk wrote:

> On 9/1/08, Denys Vlasenko <dvlasenk@xxxxxxxxxx> wrote:
> > Since there may be programs which use the fact that
> >
> > setpriority(PRIO_PROCESS, tid, value)
> >
> > prior to this patch was setting priority for selected thread,
> > this behavior is retained in case when tid != pid.
> >
> > IOW: with PRIO_PROCESS, if pid specifies a thread group leader,
> > all threads' prios are set. Otherwise, only selected thread's priority
> > is set. (Alternative can be to just fail with ESRCH).


> I would expect
> setpriority(PRIO_PROCESS, getpid())
> and
> setpriority(PRIO_PROCESS, 0)
> to have the same affect (because: which == PRIO_PRCESS, who == 0
> conventionally means "the calling process").
>
> But they do not: the latter call only changes the priority of the
> calling thread.  Is this intended?

The patch interprets 0 as the current pid rather than the current tgid.

It's up for discussion whether we should preserve old behaviour when 
specifying 0, or use a new and arguably more logical behaviour but 
possibly break old apps.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/