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?


> Yes.  It would be much better if dlopen were changed to ensure that
> every existing thread, and every newly created thread, picked up the
> space required for the new TLS variables.

Not really.  The former is not really feasible without perturbing the state
of threads blocked in syscalls and such, since you would have to wake up
every thread to run a special signal handler or something.  The latter is
more doable, but it's questionable that it's really desireable.  A
substantial part of the reason for the laziness of the whole thing is that
not every thread will use every module's TLS space, so it's a waste to
eagerly allocate all that space.  This is all part of the original design
of TLS.  That design doesn't seem to really have contemplated people using
GD TLS in signal handlers, but I have yet to be thoroughly convinced that
the desire to do so is really anything but a sign of poor design of the
modules in question at a higher level.


Thanks,
Roland


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