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.html
