public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Torvald Riegel <triegel@redhat.com>
Cc: Martin Sebor <msebor@gmail.com>,
	Joseph Myers <joseph@codesourcery.com>,
	libc-alpha@sourceware.org, Martin Sebor <msebor@redhat.com>,
	Stefan Liebler <stli@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 0/6] Add support for ISO C11 threads.h
Date: Thu, 06 Apr 2017 14:30:00 -0000	[thread overview]
Message-ID: <3fef496a-5d7f-d155-74cf-9d669e39b7ee@linaro.org> (raw)
In-Reply-To: <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

      reply	other threads:[~2017-04-06 14:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-21 13:40 Adhemerval Zanella
2017-03-21 13:40 ` [PATCH 2/6] Move mutex and condition variable definition to common header Adhemerval Zanella
2017-03-22 22:59   ` Ivo Raisr
2017-03-27 13:43   ` Torvald Riegel
2017-03-27 14:25     ` Adhemerval Zanella
2017-03-28  8:19       ` Torvald Riegel
2017-03-31 13:43         ` Adhemerval Zanella
2017-03-21 13:40 ` [PATCH 5/6] Add test cases for ISO C11 threads Adhemerval Zanella
2017-03-21 13:40 ` [PATCH 6/6] Add manual documentation for threads.h Adhemerval Zanella
2017-03-21 13:40 ` [PATCH 4/6] Add C11 threads support Adhemerval Zanella
2017-03-21 13:40 ` [PATCH 3/6] Clean pthread functions namespaces for C11 threads Adhemerval Zanella
2017-03-21 13:40 ` [PATCH 1/6] Consolidate pthreadtype.h placement Adhemerval Zanella
2017-03-21 13:48   ` Andreas Schwab
2017-03-21 15:07     ` Adhemerval Zanella
2017-03-21 16:25 ` [PATCH v3 0/6] Add support for ISO C11 threads.h Joseph Myers
2017-03-21 16:44   ` Adhemerval Zanella
2017-03-21 16:49     ` Joseph Myers
2017-03-21 17:08       ` Adhemerval Zanella
2017-03-21 20:10       ` Adhemerval Zanella
2017-03-27 13:29         ` Torvald Riegel
2017-03-27 13:29       ` Torvald Riegel
2017-03-27 16:10         ` Martin Sebor
2017-03-28  8:08           ` Torvald Riegel
2017-03-31 13:39             ` Adhemerval Zanella
2017-04-06 11:05               ` Torvald Riegel
2017-04-06 14:30                 ` Adhemerval Zanella [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3fef496a-5d7f-d155-74cf-9d669e39b7ee@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=msebor@gmail.com \
    --cc=msebor@redhat.com \
    --cc=stli@linux.vnet.ibm.com \
    --cc=triegel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).