On Wed, 2020-12-09 at 18:35 +0300, Dmitry V. Levin wrote: > On Mon, Nov 09, 2020 at 09:57:57AM -0500, Frank Ch. Eigler via Elfutils-devel > wrote: > > > [...] The problem with doing the dlopen late is that we also need > > > libcurl and initializing libcurl (as done by libdebuginfod) is not > > > thread-safe. > > > > From reading libcurl code, and that of other clients, I still believe > > this concern was & is overrated. We could back down to simple > > debuginfod_begin time mutex-protected curl_global_init calls, and we'd > > be as fine as other applications. We could ditch the dlopen / > > dso-ctor issues entirely. > > Excuse me, has there been any follow-up to this discussion?
Not really. The issue is that the documentation of curl_global_init has this very scary warning: "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. This doesn't just mean no other thread that is using libcurl." https://curl.se/libcurl/c/curl_global_init.html So we try to make sure curl_global_init is called as soon as possible by putting the call in the libdebuginfod.so libdebuginfod_ctor and libdw has a __libdwfl_debuginfod_init ctor which tries to do the dlopen of libdebuginfod as early as possible. Using ctors here is done so that we hopefully call curl_global_init before any threads are started. Frank might be right that all this is just super paranoia. But given that the libcurl developers put that scary warning in their documentation for now I am assuming we have to be that paranoid. I haven't asked them if they believe that comment is still current though. Cheers, Mark
