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

Now, that isn't a reason to not provide stronger guarantees than ISO C;
I don't see how ISO C would require TLS to *become* atomic, it just
doesn't want to give guarantees for any non-atomic variables.

> In plain C,
> there is nothing useful you can do from a signal handler whatsoever,
> nor is there anything useful that can cause a signal.

By "plain C" you mean pre-C11?

> POSIX specifies
> a lot more you can do with signal handlers (it defines many of the
> undefined aspects), but the current POSIX spec actually has lots of
> bugs; see:
> >   Will our TLS variables become lock-free atomic objects?
> I don't see how this question is related at all. Atomic in the C11
> sense has to do with synchronization between processors, not signals.
> The memory model for access to objects from signal handlers should not
> define the behavior when the signal handler accesses an object whose
> modification the signal handler interrupted, except for objects of
> type sig_atomic_t or character types (I added the latter because the
> C11 memory model already requires byte-granularity write operations),

You mean plain character types like a non-atomic char?  I doubt that
trying to give guarantees for those is right because it would prevent

> but otherwise (as long as the signal handler is sequenced to avoid
> such access, e.g. using signal masks) access to arbitrary objects from
> signal handlers should be unrestricted.

At least in ISO C++ there is an open issue how to specify the memory
model bits related to signal handling:

There has also been discussion about whether access to TLS from signal
handlers should actually be allowed at all, because implementations of
TLS access might use non-recursive locks (or other potentially
non-reentrancy-safe pieces of code) internally.

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