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

[Torvald Riegel <triegel 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
conclusion.

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
do though.

> (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...