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.
