You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A share handle added to multiple easy handles should be sufficient to share connections between each easy, and indeed this works when each easy is created fresh and attached to a share.
However I observed that when the share handle is added to a prototype easy, then new easy handles are created from that prototype using curl_easy_duphandle(), the share appears to be "lost" and must be reattached.
Attaching the share to the easy handle produced by curl_easy_duphandle() works as expected.
which would appear to actually be a reasonable step to preserve thread-safety in the curlm case where locking callbacks are unavailable(?). If fixing curl_easy_duphandle() to preserve the conn_cache isn't possible, then at least a note or two on the manpages for the share interface and/or curl_easy_duphandle() would be helpful.
After @sgolemon's report I read the man page again, and I can see how the clearing of the share-object association isn't immediately obvious - it is just inferred by that mention of "no state", but in the share handle case the state could also be seen as held by the share handle.
Of course we can argue that this is how the function is meant to work, but then I think we should also clarify this better in the documentation. We could also easily argue that a dup'ed handle should inherit the share options that the source had set. Personally, I'm sort of leaning towards the second one. One argument against that would possibly be that we've had this behavior for so long that changing this now risks introducing something weird for people and a safer route forward would be to clarify the docs around the existing functionality.