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: Async-signal-safe access to __thread variables from dlopen()ed libraries?

On 10/02/2013 09:02 AM, Ian Lance Taylor wrote:
> On Wed, Oct 2, 2013 at 2:16 AM, Torvald Riegel <> wrote:
>> On Fri, 2013-09-20 at 13:52 -0400, Rich Felker wrote:
>>> On Fri, Sep 20, 2013 at 01:41:37PM -0400, Carlos O'Donell wrote:
>>>> * Discuss the ISO C11 implications.
>>>>   ISO C11 wording in p5:
>>> The ISO C text on signal handlers is rather irrelevant.
>> While you can certainly target POSIX and treat what C defines as
>> secondary regarding signal handling, I don't agree that C's definitions
>> are irrelevant: If you want portable C11 code, you will rely on what ISO
>> C specifies.
> Yes.  However, the C11 wording is irrelevant with regard to what glibc
> should provide.  glibc is not a portable C11 library.  It's a GNU
> library.  At a bare minimum glibc needs to provide POSIX.1 support.
> And it's fine for a GNU library to provide more--e.g., glibc provides
> __thread variables long before they were in any standard.

I agree. The point of this discussion though is to make everyone aware of
the various issues, talk them out, and have answers for as many of them
as are relevant.

In the case of __thread it was clear you were using an implementation
namespace identifier which wasn't going to be portable.

Is there anything we could or should do to warn users about the potential
non-portability of a TLS variable use in a signal handler other than to
document this in the manual?


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