This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH roland/nptl] NPTL: Don't (re)validate sched_priority in pthread_create.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Tue, 18 Nov 2014 23:17:24 -0500
- Subject: Re: [PATCH roland/nptl] NPTL: Don't (re)validate sched_priority in pthread_create.
- Authentication-results: sourceware.org; auth=none
- References: <20141118205213 dot 90CF92C3B21 at topped-with-meat dot com>
On 11/18/2014 03:52 PM, Roland McGrath wrote:
> Now that pthread_attr_setschedparam validates the value, it should no
> longer be possible to see an invalid value in pthread_create. I've
> verified that in Linux the min/max values depend only on the policy
> selection and not on any dynamic factors that might have changed between
> pthread_attr_setschedparam and pthread_create.
>
> The one wrinkle is if the user called pthread_attr_setschedparam before
> pthread_attr_setschedpolicy and the sched_priority value was valid for the
> old policy but invalid for the new one. POSIX does not seem to provide for
> pthread_attr_setschedpolicy being able to return an error in this case, or
> for it to do something else like reset the sched_param bits to defaults on
> pthread_attr_setschedpolicy if the old bits don't make sense for the new
> policy. So in this situation, pthread_create failing with EINVAL appears
> to be the best we can do--and that's what we do now. But removing this
> check in pthread_create doesn't change that behavior observably: the thread
> will be started up and then create_thread will cancel it when the
> sched_setscheduler syscall fails, propagating the error code (presumably
> still EINVAL) back to pthread_create. So this user misuse of the API is
> detected with significantly more overhead, but I don't think that matters.
>
> Tested x86_64-linux-gnu.
>
> If nobody objects soon, I'll commit this.
Failure is certainly not what we want to optimize, and removing this
code is certain to make pthread_create faster, and I agree that EINVAL
is the best we can do here.
What would like to know is: Have you tested the failure mode?
If you haven't, please do, and if it works sanely, then LGTM.
What is the impetus behind this change?
Cheers,
Carlos.