This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH roland/nptl] NPTL: Don't (re)validate sched_priority in pthread_create.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Thu, 20 Nov 2014 10:59:44 -0800 (PST)
- 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> <546C19D4 dot 6060409 at redhat dot com> <20141120012434 dot A1F4C2C3AD8 at topped-with-meat dot com> <546DFB0D dot 30203 at redhat dot com>
> > I've written up a test for the expected EINVAL diagnosis. It depends
> > on constructing a pthread_attr_t with invalid scheduling parameters,
> > which AFAIK is possible only by using pthread_attr_setschedparam while
> > the pthread_attr_t is set to one scheduling policy where a given
> > struct sched_param is valid and then using pthread_attr_setschedpolicy
> > to switch it to a policy where those values are invalid. This
> > requires some assumptions about the policies and their parameters, but
> > those are predictable enough at least for Linux.
> Should this even be possible?
I can't see how it could be ruled out.
POSIX doesn't put any requirements on the order in which you call
pthread_attr_setschedparam and pthread_attr_setschedpolicy.