curl_global_init.3: Add Windows-specific info for init via DLL

- Add to both curl_global_init.3 and libcurl.3 the caveat for Windows
that initializing libcurl via a DLL's DllMain or static initializer
could cause a deadlock.

Bug: https://github.com/bagder/curl/issues/586
Reported-by: marc-groundctl@users.noreply.github.com

diff --git a/docs/libcurl/curl_global_init.3 b/docs/libcurl/curl_global_init.3
index 77172be67011e36e6151036a16b1dc1da1837caa..2e489c1a8f45bbb6d1e7d29325c7a0f74946c46e 100644 (file)
--- a/docs/libcurl/curl_global_init.3
+++ b/docs/libcurl/curl_global_init.3
@@ -50,6 +50,10 @@ This doesn't just mean no other thread that is using libcurl.  Because
 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.
+
 See the description in \fBlibcurl(3)\fP of global environment requirements for
 details of how to use this function.
 

diff --git a/docs/libcurl/libcurl.3 b/docs/libcurl/libcurl.3
index 05034c98e5136b1a2e14221f2d7bb569e6e8cd36..e7709c04d0e685f82e1ab7af6ea6929275e12811 100644 (file)
--- a/docs/libcurl/libcurl.3
+++ b/docs/libcurl/libcurl.3
@@ -194,6 +194,9 @@ object as the program starts up and the destructor as it terminates.  As the
 author of this libcurl-using module, you can make the constructor call
 \fIcurl_global_init(3)\fP and the destructor call \fIcurl_global_cleanup(3)\fP
 and satisfy libcurl's requirements without your user having to think about it.
+(Caveat: 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.)
 
 \fIcurl_global_init(3)\fP has an argument that tells what particular parts of
 the global constant environment to set up.  In order to successfully use any