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]

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


On 9/18/13 9:38 PM, Rich Felker wrote:

We really need a TLS that is both async-signal safe, and can be used from
dlopen()ed shared library.

For what it's worth, we have fully async-signal-safe and fail-safe (no
possibility to abort due to allocation failure) dynamic TLS in musl
libc.

How does that work?


Is this sufficient? Unless you take precautions, I think you could run
into the situation where a signal handler is invoked while the thread
is setting up its dynamic TLS, thereby possibly discarding changes
made to TLS from the signal handler and possibly leaking memory.
Fixing these issues is possible but difficult; the cleanest approach I
know uses atomic operations -- something of the form:

AFAIU, Andrew's patch blocks all signals while dynamic allocation is taking place, to prevent self-reentry via a signal handler, and atomic operations to prevent a race with another thread.

But I don't (yet) understand that patch well.

Thanks,


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