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 22/01/16 14:49, Torvald Riegel wrote:
On Tue, 2016-01-12 at 14:28 +0000, Szabolcs Nagy wrote:tl;dr: if your libc has non-noop dlclose it must use a global lock in dlopen/dlclose/thread creation/tls access and user code must not run while that lock is held (e.g. signals must be blocked)Depending on what the non-noop functionality is, it might be possible to still implement this in a nonblocking way (so you avoid the blocking sync vs. signals and reentrancy issue).
the non-noop functionality is that dlclose frees memory that pthread_create and tls access may look at (the link_map of a dso). i guess lock-free garbage collection is a possibility (e.g. refcounting, except tls access cannot call free so it's not entirely trivial.)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |