Re: [PATCH] nptl: Add test nptl/tst-pthread-perthread-inherit

[Carlos O'Donell <carlos at redhat dot com>]

On 7/1/19 12:47 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 6/30/19 5:10 AM, Florian Weimer wrote:
>>> * Carlos O'Donell:
>>>
>>>>> +               NULL attribute at one level, then that is true for both
>>>>> +               kinds of properties.  */
>>>>> +            if ((outer_perthreadfs == null_attribute)
>>>>> +                != (outer_perthreadids == null_attribute))
>>>>> +              continue;
>>>>> +            if ((inner_perthreadfs == null_attribute)
>>>>> +                != (inner_perthreadids == null_attribute))
>>>>> +              continue;
>>>>
>>>> Do you *have* to exclude these? Could we let the extra tests run?
>>>>
>>>> Sure they don't make sense, but why do you say they are "impossible?"
>>>
>>> If threadfs requires a NULL attribute, and threadids requres
>>> PTHREAD_PER_THREAD_NP, then we cannot run the subtest because the NULL
>>> value does not carry any attributes.
>>
>> I don't follow.
>>
>> You have two functions, pthread_attr_setperthreadfs_np, and
>> pthread_attr_setperthreadids_np.
>>
>> You want to call them with the permutation of their options
>> and check the results.
>>
>> At an API level the arguments used to call them are unrelated.
>>
>> I don't understand what you what to express in the last paragraph.
> 
> pthread_create has only one attribute argument.  If it is NULL, it
> means that both attributes are absent.

Ah, In my mind I was just "promoting" the NULL attribute to a non-NULL
when an attribute is needed i.e. the merger of both requirements ends
up being a non-NULL attribute.

In your opinion this becomes a violation of the test constraint.
I see your point. I'm OK with the code as-is then.

-- 
Cheers,
Carlos.