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
This commit is contained in:
Jay Satiro 2016-01-04 17:44:39 -05:00
parent b82359643d
commit 19ca40100b
2 changed files with 7 additions and 0 deletions

View File

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

View File

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