This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions



On 15/11/2017 10:49, Florian Weimer wrote:
> On 11/15/2017 01:43 PM, Adhemerval Zanella wrote:
>>
>>
>> On 15/11/2017 10:03, Florian Weimer wrote:
>>> On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:
>>>>
>>>>
>>>> On 15/11/2017 06:09, Florian Weimer wrote:
>>>>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:
>>>>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC
>>>>>> 9899:2011),
>>>>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,
>>>>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.
>>>>>>
>>>>>> Mostly of the definitions are composed based on POSIX conterparts,
>>>>>> such as
>>>>>> thrd_t (using pthread_t).
>>>>>
>>>>> I have skimmed the C11 discussion of these types, and C11 says that
>>>>> mtx_t et al. are “identifiers”.  To me, this suggests they are
>>>>> handles, just like pthread_t in the POSIX threads implementation.
>>>
>>>> My understanding is "identifiers" follow the definition from C11 6.2.1
>>>> which does not exclude a tag/struct to represent it.
>>>
>>> I don't think “identifier” is used in this sense here.
>>>
>>> The standard says (7.2.6.1/4):
>>>
>>> “
>>> The types are
>>> \begin{quote}
>>>    \verb|cnd_t|
>>> \end{quote}
>>> which is a complete object type that holds an identifier for a
>>> condition variable;
>>> ”
>>>
>>> The “holds an identifier” suggests to me that this use of the term
>>> “identifier” does not refer to the C language construct.  The
>>> definitions in ISO/IEC 2382:2015(en) do not seem to be applicable,
>>> either.
> 
>> I find it quite inconsistent and improbable that the threads definition
>> in C11
>> standard is using a defined vocabulary in a different meaning than the rest
>> of document.
> 
> But how can a complete object *type* hold a C identifier?  The language does not support that.  We don't have call-by-name or anything like that.

Why do we need call-by-name to provide a complete identifier for C11 mtx_t
type? My understanding is we have the init functions to initialize the
objects and C11 threads avoid static initializers.

> 
> So this usage doesn't make sense to me, so I assume that something else is meant here.
> 
> I'm trying to get access to the WG papers on which the text is based. Maybe those illuminate what is meant here.


Similar objections were already raised in DR#493 [1], more specifically for

"1. What is the behavior of mtx_init() when called with a pointer to an object
initialized to all zeros (such as a mutex object with static storage duration)? 
Are such calls valid, or if not, must the function fail by returning thrd_error, 
or is its behavior unspecified, or perhaps undefined? (If it is the same as 
calling it on an uninitialized object then how does one statically initialize a
mutex?)"

The committee discussion for this specific topic is aiming for:

"Problems with mtx_t

The semantics of copying a mtx_t are not specified, much like FILE §7.21.3p6."

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_493


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]