@@ -596,10 +596,16 @@ __pthread_create_2_1 (newthread, attr, start_routine, arg)
{
/* Use the scheduling parameters the user provided. */
if (iattr->flags & ATTR_FLAG_POLICY_SET)
- pd->schedpolicy = iattr->schedpolicy;
+ {
+ pd->schedpolicy = iattr->schedpolicy;
+ pd->flags |= ATTR_FLAG_POLICY_SET;
+ }
if (iattr->flags & ATTR_FLAG_SCHED_SET)
- /* The values were validated in pthread_attr_setschedparam. */
- pd->schedparam = iattr->schedparam;
+ {
+ /* The values were validated in pthread_attr_setschedparam. */
+ pd->schedparam = iattr->schedparam;
+ pd->flags |= ATTR_FLAG_SCHED_SET;
+ }
if ((pd->flags & (ATTR_FLAG_SCHED_SET | ATTR_FLAG_POLICY_SET))
!= (ATTR_FLAG_SCHED_SET | ATTR_FLAG_POLICY_SET))
Fixed thusly. This does change things slightly from the status quo ante, but I suspect the old state was not what we really intended to be doing. Previously, ATTR_FLAG_{POLICY,SCHED}_SET would not be set in PD->flags at creation time when IATTR->flags had the bit set (and so PD->schedfoo has value copied from IATTR->schedfoo) but *would* be set when IATTR->flags had the bit clear (and so PD->schedfoo has a value gleaned via the sched_getfoo syscall on the pthread_create caller). Logically that seems backwards at best. Practically, I think the only effect is whether pthread_getschedparam, __pthread_tpp_change_priority, and __pthread_current_priority yield values already cached in the calling thread's struct pthread or refresh that cache by making syscalls (so there is no effect on the second or later repeated call to one of those). Per the comment in pthread_getschedparam, no kosher program could notice the difference. I think the status quo ante was just an oversight. Thanks, Roland 2014-11-21 Roland McGrath <roland@hack.frob.com> * nptl/pthread_create.c (__pthread_create_2_1): Set ATTR_FLAG_POLICY_SET and/or ATTR_FLAG_SCHED_SET in PD->flags when copying values from IATTR into PD.