well.
If you did not already call curl_global_init(3) before calling this function,
-curl_easy_init(3) does it automatically. This may be lethal in multi-threaded
-cases, if curl_global_init(3) is not thread-safe in your system, and it may
+curl_easy_init(3) does it automatically. This can be lethal in multi-threaded
+cases for platforms where curl_global_init(3) is not thread-safe, and it may
then result in resource problems because there is no corresponding cleanup.
You are strongly advised to not allow this automatic behavior, by calling
value unless you are familiar with it and mean to control internal operations
of libcurl.
-This function is thread-safe since libcurl 7.84.0 if
-curl_version_info(3) has the CURL_VERSION_THREADSAFE feature bit set
-(most platforms).
-
-If this is not thread-safe, you must not call this function when any other
-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
-curl_global_init(3) calls functions of other libraries that are
-similarly thread unsafe, it could conflict with any other thread that uses
-these other libraries.
+This function is thread-safe on most platforms. Then curl_version_info(3) has
+the `threadsafe` feature set (added in 7.84.0).
+
+If this is not thread-safe (the bit mentioned above is not set), you must not
+call this function when any other 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 curl_global_init(3) 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