This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Should we declare errno with __thread on x86?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org, Roland McGrath <roland at hack dot frob dot com>
- Date: Wed, 13 Apr 2016 14:37:58 +0200
- Subject: Re: [RFC] Should we declare errno with __thread on x86?
- Authentication-results: sourceware.org; auth=none
- 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>
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.
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
> (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...