From ae8a329e8108b936023bda387624c7683014b3d0 Mon Sep 17 00:00:00 2001 From: Jay Satiro Date: Wed, 8 Jun 2022 03:02:51 -0400 Subject: [PATCH] curl_global_init.3: Separate the Windows loader lock warning This is a slight correction of the parent commit which implied the loader lock warning only applied if not thread-safe. In fact the loader lock warning applies either way. Ref: https://github.com/curl/curl/pull/8972#discussion_r891987030 --- docs/libcurl/curl_global_init.3 | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/libcurl/curl_global_init.3 b/docs/libcurl/curl_global_init.3 index ce0b1dcea7..cf654fab61 100644 --- a/docs/libcurl/curl_global_init.3 +++ b/docs/libcurl/curl_global_init.3 @@ -53,9 +53,11 @@ thread in the program (i.e. a thread sharing the same memory) is running. This does not just mean no other thread that is using libcurl. Because \fIcurl_global_init(3)\fP calls functions of other libraries that are similarly thread unsafe, it could conflict with any other thread that uses -these other libraries. If you are initializing libcurl from a Windows DLL you -should not initialize it from DllMain or a static initializer because Windows -holds the loader lock during that time and it could cause a deadlock. +these other libraries. + +If you are initializing libcurl from a Windows DLL you should not initialize it +from DllMain or a static initializer because Windows holds the loader lock +during that time and it could cause a deadlock. See the description in \fIlibcurl(3)\fP of global environment requirements for details of how to use this function.