This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Should we declare errno with __thread on x86?


It's not machine-specific (or even really OS-specific).
All non-Hurd configurations use the TLS errno.
I don't know why you mentioned x86 specifically.

References from the libc source tree already do use TLS directly
(see include/errno.h).

So I take it you are talking about the public <errno.h> declaration.
Is that what you meant?

The simple reason we haven't done this before is because we've never done
this before.  There are no TLS symbols in our public ABIs.  When we first
changed the internal implementation to use TLS, compilers' and other tools'
support for TLS was still very new and unreliable.  Conservatism has kept
us where we are since then.

Since what you are suggesting is a change motivated solely by performance,
we should see some real-world or benchmark measurements of some kind to
justify it.  A micro-benchmark of reading errno is not that interesting,
especially since naive intuition would expect that errno is examined only
(or almost entirely) in error paths that are not hot paths and so that
same intuition would expect that real-world impact would be negligible.

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 expect that whatever we conclude about errno will apply just as well to
h_errno (and maybe _res).


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]