How can we be sure go does not use static tls ? On Mon, Oct 31, 2016 at 10:35 AM, Nadav Har'El <[email protected]> wrote:
> > On Mon, Oct 31, 2016 at 10:35 AM, Benoît Canet < > [email protected]> wrote: > >> >> >> On Mon, Oct 31, 2016 at 9:30 AM, Nadav Har'El <[email protected]> wrote: >> >>> >>> All this discussion explained why we need to call init_static_tls() on >>> the parent thread - not it was important to delay the shared object's >>> initialization until the child thread. >>> >> >> Go initialization function will touch the non statis tls area. So the >> thread creation need to allocate them first else the following call to the >> go runtime will just find a blank tls are and be very confused. >> > > The TLS-allocation-for-new-threads issue is only relevant for static TLS. > For "normal" (general dynamic) TLS model, each thread (whether an old > thread or a new thread) will allocate the TLS needed for an object the > first time this object's code accesses TLS - see __tls_get_addr. > So it should be fine to get_library() a shared object, and then call a > function from it which uses non-static TLS in the original thread (or any > other pre-existing thread which shares the same get_program(). > > But I just realized another issue which might explain the problem you see: > __tls_get_addr() was written back when we had a single "program" running, > and it kept a list of shared object indices in that single "program". Maybe > now that we can have several of those (with those "elf name spaces"), we > made a mess here, because if the parent thread has a different > get_program(), it will not work as expected? > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
