Hi - > > 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. > 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. - FChE