Re: Using libcurl in another library, when/if to call curl_global_init?

[Mark Wielaard <mark@klomp.org>]

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