On Tue, Jan 16, 2018 at 12:03 PM, Nadav Har'El <n...@scylladb.com> wrote:
> > On Mon, Jan 15, 2018 at 11:25 PM, Waldek Kozaczuk <jwkozac...@gmail.com> > wrote: > >> Yep I will try to follow your advice about the "least resistance" order. >> >> I could not find anything about " TLS-related" or "the order of when the >> TLS variables were allocated or initialized" related patches. Is it maybe >> here - https://groups.google.com/forum/#!searchin/osv-dev/Golang$ >> 20and$20TLS%7Csort:date/osv-dev/qLfRBRRUIHM/ONaEEtoLAwAJ? >> >> Waldek >> > > The patch I remembered was, I think, titled "elf/app: Delay elf object > initialization". I see that I had many comments on v2 of that patch, on the > whole approach of this patch, but don't remember if anything changed in v4, > or whether my reservations still hold. Let's do this patch last, if > possible :-) > I think this was my main concern in that thread, that this patch only papered over a bigger bug: "So it looks like we have here a pre-existing bug in the way static TLS (the "initial-exec" model) works. The program::get_library() function does not, and should not, create a new thread (only the osv::application wrapper does). One can load a library and call a function from it in the current thread, without creating a new thread . The problem is that get_library() calls init_static_tls() which, as far as I remember only changes the way that new threads will be created (when they will call setup_tcb()) - and does not modify the current thread's TLS area. So in a program which uses static TLS (the initial-exec model), and runs code from the library without starting a new thread, it will not have access to its TLS variables. By the way, I think we have an even bigger mess there. It turns out that setup_tcb() knows which objects' static TLS to set up for the new thread by using this thread's thread::_app_runtime. Which means that this thing will not work correctly without using osv::application anyway - someone will not be able to run code with static TLS by using get_library() alone anyway. An additonal problem: I recently modified osv::run() to not create a new thread - so now that would not work on code with static TLS. One last complication: Even if get_library() did modify the current thread's tls, who would restore it when the library is unloaded? This is one big messy situation :-( " > > Nadav. > -- 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 osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
