This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Should we declare errno with __thread on x86?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel 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 11:17:42 +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>
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.
Another consideration is sharing of errno across dlmopen/static dlopen
boundaries, which is exactly the opposite (more sharing instead of
less). Putting errno into the TCB would likely achieve that, which is
easier with the __errno_location scheme, I think. But it can be done
with TLS variable access as well because we control the dynamic linker.
(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. :)