This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Should we declare errno with __thread on x86?
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Torvald Riegel <triegel at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, <nd at arm dot com>, Alexander Monakov <amonakov at ispras dot ru>
- Date: Wed, 13 Apr 2016 13:59:34 +0100
- Subject: Re: [RFC] Should we declare errno with __thread on x86?
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <CAMe9rOrb8XPsTUKHMw7F-+iy7D=UH=5XP_K06wDAwka+RRDCgw at mail dot gmail dot com> <20160318231420 dot A1C7E2C3C66 at topped-with-meat dot com> <1460485835 dot 3869 dot 271 dot camel at localhost dot localdomain> <570E0EB6 dot 2020707 at redhat dot com> <1460551078 dot 3869 dot 348 dot camel at localhost dot localdomain>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 13/04/16 13:37, Torvald Riegel wrote:
> On Wed, 2016-04-13 at 11:17 +0200, Florian Weimer wrote:
>> On 04/12/2016 08:30 PM, Torvald Riegel wrote:
>>> On Fri, 2016-03-18 at 16:14 -0700, Roland McGrath wrote:
>>>> If real-world performance measurement does in fact justify it, we'll still
>>>> need to be very circumspect about potential pitfalls (applications built
>>>> with older compilers, etc). We'll need to put a lot of thought into it
>>>> collectively to achieve confidence that it's a safe and sensible change for
>>>> all our users.
>>> I agree that this would need a thorough investigation and assessment of
>>> risks of doing that. One risk I see is that it would likely make it
>>> harder for us to support errno on threads of execution that are not OS
>>> threads (eg, coroutines, or under work-stealing implementations).
>> It will not be worse than what we currently have because
>> __errno_location is declared const. Already today, resuming a call
>> stack on a thread other the one on which it was suspended results in
>> undefined behavior. This also applies to most forms of TLS access (if
>> not all of them), again due to compiler caching of TLS variable addresses.
> That is a an interesting point, good catch. But I disagree with your
> The const attribute is specified as asserting that the function does not
> examine any data except the arguments. __errno_location has no
> arguments, so it would have to return the same values *every time*.
> This works in a single-threaded program, but not in a multi-threaded
> one. Thus, I think that strictly speaking, it should not be const.
that was my conclusion too, reading the second point in
but there was no further discussion then..
> We could argue that this magically is meant to always be in the context
> of a specific thread. Ignoring that GCC doesn't define threads itself
> (especially in something like NPTL which is about creating a notion of
> threads), we could still assume that this works because in practice, the
> compiler and its passes can't leak knowledge across a function used in
> one thread and other one used in another thread. But then this would
> still hold for coroutines, I guess, if we can manage to have
> __errno_location return a coroutine-specific location if this is
> executed in a coroutine. It would limit the amount of inlining we can
> do though.
>> (Your job is to make sure that we can implement C++ coroutines with
>> something substantially more lightweight than threads, while still
>> keeping all our existing binaries, particularly libraries. :)
> TLS, signals, and all these things make this challenging. Maybe some
> execution agents will only work with C++ code; it could happen that we
> just can't preserve some of the old semantics...