Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Using libcurl in another library, when/if to call curl_global_init?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Mark Wielaard via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 05 Apr 2022 18:19:13 +0200
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
Date: Tue, 05 Apr 2022 18:19:13 +0200
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
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-04-05