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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |