From: Jay Satiro <raysatiro@yahoo.com>
Date: Wed, 8 Jun 2022 07:02:51 +0000 (-0400)
Subject: curl_global_init.3: Separate the Windows loader lock warning
X-Git-Tag: curl-7_84_0~73
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ae8a329e8108b936023bda387624c7683014b3d0;p=thirdparty%2Fcurl.git

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

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.