On Tue, 2022-04-05 at 17:36 +0200, Daniel Stenberg wrote: > On Thu, 31 Mar 2022, Mark Wielaard via curl-library wrote: > > > But we are struggling a bit with how to safely/correctly initialize > > libcurl. > > Are you struggling to meet the requirement as per the documentation > or are you seeing actual runtime issues?
Struggling with the requirements as per the documentation "You must not call it [curl_global_init] when any other thread in the program is running". Especially combined with having users who would not like to pay the cost of initializing libcurl (in FIPS mode) when the program isn't explicitly using the remote resource functionality of our library (but is still linked to it). We are a library that is (sometimes) dlopened, so we cannot guarantee that when we call curl_global_init no other thread in the program is running. But we try to mitigate that by having a __attribute__((constructor)) ctor that just does curl_global_init(CURL_GLOBAL_DEFAULT); Which in most cases (especially if we aren't dlopened) should make sure we run before the program has any chance to start any new threads. But that of course also makes sure that we (or the program linking to our library) always pays the cost for calling curl_global_init, which at least in FIPS mode does some non-trivial checks. So we are wondering if instead we could do lazy initialization just before we know we will actually need to load a remote resource. We could wrap such an initialization inside a pthread_once, so at least with multiple threads we don't race against ourselves given that curl_global_init itself is not thread-safe (it uses a unguarded initialized int). But Florian just pointed out that we would still race against other uses of libcurl in the program, in case they also didn't call curl_global_init before starting any other threads. Cheers, Mark
