Hi Frank, On Tue, Nov 19, 2019 at 11:20:34AM -0500, Frank Ch. Eigler wrote: > > > Doing a redundant initialization later is not a problem; there is a > > > counter in there. The problematic case would be > > > - a multithreaded application > > > - loading debuginfod.so multiply concurrently somehow > > > - and calling the solib ctor concurrently somehow > > > - and all of this concurrently enough to defeat libcurl's init-counter > > > > > > IMHO, not worth worrying about. Someday libcurl will do the right > > > thing (tm) and plop this initialization into their solib ctor. > > > > I do worry about this because any multi-threaded app that uses libdw.so > > might cause trouble because we dlopen libdebuginfod.so lazily and then > > it will call curl_global_init () which explicitly says: > > > > This function is not thread safe. You must not call it when any > > other thread in the program (i.e. a thread sharing the same memory) > > is running. [...] > > That's what the doc says. What the code does, as far back as the year > 2001, is have a static flag/counter in curl_global_init() that > prevents multiple initialization.
But the warning isn't about multiple initialization. It is about initialization when other threads are running that might be using any of the libcurl support libraries. > > That is why I think doing the dlopen of libdebuginfod.so eagerly from a > > libdw.so constructor function or _init might be necessary to make sure > > no other threads are running yet. > > That's not even enough for "sure" - if we're so deep in the > hypotheticals hole, an application could be dlopen()ing libdw.so > itself. It could, but I think that would be unlikely. We can at least document that it is unsafe to use libdw.so with dlopen. But if it is done, could we detect it and not do the loading of libdebuginfod.so in that case? Thanks, Mark
