Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Oct 02, 2013 at 11:16:44AM +0200, 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 7.14.1.1 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.

It depends on what you mean by "portable". There's absolutely nothing
useful you can do with a signal handler if writing portable C (since
there's not even a portable way to expect a signal to happen). My
interpretation of the presence of signals in the C language is just to
provide a common interface for things like interrupt handling on
low-level implementations without an OS and similar facilities on an
OS, which would be OS-specific if you don't assume your OS conforms to
the standard to which all OS's _should_ conform, POSIX.

My point is that if you're doing anything fancy from signal handlers,
you're either assuming a specific OS or bare-metal environment, or
assuming POSIX. And the latter is the case that's interesting to us.

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

No, even C11.

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

The optimizations are already forbidden by C11 and POSIX memory
models. For example, if you have:

	char x[2];

it's legal for threads A and B to access x[0] and x[1] concurrently
without any locking.

> > 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:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3633.html
> 
> 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.

I would simply call these bad implementations. It is not hard to make
TLS work in an async-signal-safe way.

Rich