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: Paul Groke via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 06 Apr 2022 19:15:40 +0200
On Tue, Apr 5, 2022, at 17:36, Daniel Stenberg via curl-library wrote:
> There isn't much left in the third party libraries that isn't threadsafe so
> I'm quite interested in knowing. The "not thread-safe" part is mostly
> theoretic now with modern versions of libraries (such as OpenSSL).
I'd say the biggest problem is that libcurl's global_init function is itself not thread-safe.
global_init does quite a lot of stuff - with zero synchronization.
And then there's the global state, which is always a potential problem when there are multiple users of libcurl in the same process - with or without multi-threading. Stuff like the memory management function pointers and anything that's controlled by init-flags.
The only way I see to safely use libcurl in a generic library is to statically link to libcurl without exporting any of its symbols.
What should be relatively easy is to make global_init thread-safe. And it would be good enough for processes where all libcurl users agree on the init-flags and don't use custom memory management functions.
Making it entirely multi-user friendly would be a lot harder. It would mean that e.g. curl_global_init(CURL_GLOBAL_SSL) has to initialize the SSL backend even if there was a preceding call of curl_global_init(CURL_GLOBAL_NOTHING) - and no call of curl_global_cleanup in-between. And that of course in a way that allows concurrent calls into libcurl on other threads, without anything going wrong.
And it would also mean to drop curl_global_init_mem - or at least outlaw its use in multi-threaded applications.
Date: Wed, 06 Apr 2022 19:15:40 +0200
On Tue, Apr 5, 2022, at 17:36, Daniel Stenberg via curl-library wrote:
> There isn't much left in the third party libraries that isn't threadsafe so
> I'm quite interested in knowing. The "not thread-safe" part is mostly
> theoretic now with modern versions of libraries (such as OpenSSL).
I'd say the biggest problem is that libcurl's global_init function is itself not thread-safe.
global_init does quite a lot of stuff - with zero synchronization.
And then there's the global state, which is always a potential problem when there are multiple users of libcurl in the same process - with or without multi-threading. Stuff like the memory management function pointers and anything that's controlled by init-flags.
The only way I see to safely use libcurl in a generic library is to statically link to libcurl without exporting any of its symbols.
What should be relatively easy is to make global_init thread-safe. And it would be good enough for processes where all libcurl users agree on the init-flags and don't use custom memory management functions.
Making it entirely multi-user friendly would be a lot harder. It would mean that e.g. curl_global_init(CURL_GLOBAL_SSL) has to initialize the SSL backend even if there was a preceding call of curl_global_init(CURL_GLOBAL_NOTHING) - and no call of curl_global_cleanup in-between. And that of course in a way that allows concurrent calls into libcurl on other threads, without anything going wrong.
And it would also mean to drop curl_global_init_mem - or at least outlaw its use in multi-threaded applications.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-04-06