Gary Maxwell helped us clarify that CURLOPT_SHARE specificly needs the locking

functions if the easy handles are used in multiple threads

diff --git a/docs/libcurl/curl_easy_setopt.3 b/docs/libcurl/curl_easy_setopt.3
index dd3473b997d6a3ff8f491670c590c945318d0498..9599b65e6b2588982492dffafff1822545c6dad8 100644 (file)
--- a/docs/libcurl/curl_easy_setopt.3
+++ b/docs/libcurl/curl_easy_setopt.3
@@ -1726,8 +1726,9 @@ Pass a share handle as a parameter. The share handle must have been created by
 a previous call to \fIcurl_share_init(3)\fP. Setting this option, will make
 this curl handle use the data from the shared handle instead of keeping the
 data to itself. This enables several curl handles to share data. If the curl
-handles are used simultaneously, you \fBMUST\fP use the locking methods in the
-share handle. See \fIcurl_share_setopt(3)\fP for details.
+handles are used simultaneously in multiple threads, you \fBMUST\fP use the
+locking methods in the share handle. See \fIcurl_share_setopt(3)\fP for
+details.
 
 If you add a share that is set to share cookies, your easy handle will use
 that cookie cache and get the cookie engine enabled. If you unshare an object