[PATCH v3 0/6] Add support for ISO C11 threads.h
Adhemerval Zanella
adhemerval.zanella@linaro.org
Thu Apr 6 14:30:00 GMT 2017
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
More information about the Libc-alpha
mailing list