Re: Wrong connection reuse case for Share interface

Thanks for clarification. Somehow, I missed this behavior change.

But it used to be working OK in the older libcurl versions, so it may seem like regression for folks upgrading from older versions.

And the problem can be that the order of how share is set to NULL and handle is removed can be deeply buried in some framework or 3rd party library,
which is not easy to change to work around this new limitation.

Hopefully, as you said, this case will be handled better in the future, and setting share to NULL before removing handle from the multi will close the connection rather result into UB.

Thanks!
Dmitry


-----Original Message-----
From: Daniel Stenberg <[email protected]> 
Sent: Thursday, July 2, 2026 9:20 AM
To: Dmitry Karpov via curl-library <[email protected]>
Cc: Dmitry Karpov <[email protected]>
Subject: [EXTERNAL] Re: Wrong connection reuse case for Share interface

On Wed, 1 Jul 2026, Dmitry Karpov via curl-library wrote:

>  * Run the transfer using multi interface to some point where it will 
> be  abandoned (i.e. application may make this decision due to lack of 
> space  where to write incoming data etc)

>  * Set share to NULL on "abandoned" easy handle to avoid using the 
> share on  that transfer further and remove it from the multi handle 
> (via  curl_multi_remove_handle()).

Sharing was not designed to get dynamically modified during transfers. You should remove the easy handle from the multi first, then change sharing options.

The CURLOPT_SHARE man page has this wording since a couple of months back:

   Warning: adding a *share* and then setting it to NULL while the transfer is
   ongoing is discouraged and may lead to undefined behavior.

That said, we can of course add code to handle this specific case better.

-- 

  / daniel.haxx.se || https://rock-solid.curl.dev
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html