This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 0/6] Add support for ISO C11 threads.h
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org, Martin Sebor <msebor at redhat dot com>, Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- Date: Thu, 6 Apr 2017 11:29:58 -0300
- Subject: Re: [PATCH v3 0/6] Add support for ISO C11 threads.h
- Authentication-results: sourceware.org; auth=none
- References: <1490103612-9401-1-git-send-email-adhemerval.zanella@linaro.org> <alpine.DEB.2.20.1703211623480.8480@digraph.polyomino.org.uk> <662cb906-1845-1164-5b61-a575c5edfe07@linaro.org> <alpine.DEB.2.20.1703211644540.8480@digraph.polyomino.org.uk> <1490606755.26906.423.camel@redhat.com> <5a09c4f0-f0cc-7252-110d-8443533e1e98@gmail.com> <1490688522.26906.465.camel@redhat.com> <4b4ab845-95b4-5fed-58ab-99b02a776a52@linaro.org> <1491476708.5374.110.camel@redhat.com>
On 06/04/2017 08:05, Torvald Riegel wrote:
> On Fri, 2017-03-31 at 10:39 -0300, Adhemerval Zanella wrote:
>>
>> On 28/03/2017 05:08, Torvald Riegel wrote:
>>> On Mon, 2017-03-27 at 10:10 -0600, Martin Sebor wrote:
>>>> I've reviewed the DRs and your comments below. I agree with
>>>> your view and just for clarity provide some additional comments
>>>> of my own.
>>>
>>> Thanks!
>>>
>>>> There's been a lot of talk over the last few WG14 meetings about
>>>> the whole threads section needing an overhaul. I don't know if
>>>> anyone is actually working on it but if it were to happen (for
>>>> C2X) there is some risk that an implementation coded to the C11
>>>> spec not conforming to the cleaned up and improved C2X spec.
>>>
>>> I'd hope that they wouldn't deviate from what C++ specifies. I'm
>>> monitoring C++ changes, including whether anything would result in
>>> required changes for glibc. IOW, if C doesn't deviate from C++, we
>>> shouldn't need additional changes just for C.
>>>
>>
>> Thanks for both extensive inputs and discussion. From the comments I
>> see that a current C11 thread based on POSIX could be still be feasible,
>> however I am not sure if we should prevent its implementation based on
>> the C2X possible different spec.
>>
>> In any way, I see that the still pending DR493 should not pose any
>> implementation issues (we can work out on the wrapper if any other
>> requirement is posed).
>>
>> So I would like the input from the community whether implementing C11
>> in GLIBC is desirable and if current approach based is most correct
>> one.
>
> I think it is desirable, and it's probably about time that we have
> something. I'm not aware of anything that would be a huge problem. C11
> is in several cases much closer to what we implement than POSIX.
>
> I still think it may have been nice to have smaller data structure sizes
> for things like mutexes; however, we don't have consensus in the
> community to shrink them, and we don't have the resources I believe to
> really investigate this.
Indeed, however this would add some complication to use the POSIX internal
implementation directly. We would need to create a common internal function
that would be called by POSIX and C11 wrappers, I will check this out in my
next rebase.
>
> I haven't looked at the TLS issues, or at how you organize headers and
> such. I also haven't yet reviewed all of your patches. But unless
> somebody complains, IMHO we should just go forward with what you have.
> Supporting the C11 threading support functions in the next release would
> be nice.
Now with the removal of the ancient macro CALL_THREAD_FCT [1] and the
consolidation of pthreadtypes.h in a different patchset [2] [3], I will
rebase the changes and send a new patchset. The consolidation of
pthreadtypes.h is mostly a mechanical change without expected code changes,
so I think it should be safer to push i
[1] https://sourceware.org/ml/libc-alpha/2017-04/msg00057.html
[2] https://sourceware.org/ml/libc-alpha/2017-04/msg00018.html
[3] https://sourceware.org/ml/libc-alpha/2017-04/msg00019.html