This is the mail archive of the 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?

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. :)


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