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

[Florian Weimer]

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

Florian