curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: curl_version_info() thread-safety

From: Patrick Monnerat via curl-library <>
Date: Sun, 25 Sep 2022 13:13:24 +0200

On 9/25/22 09:00, Ray Satiro via curl-library wrote:
> On 9/24/2022 12:22 PM, Patrick Monnerat via curl-library wrote:
> Shouldn't the backend have been selected via ssl initialization by the
> time multissl_version is called? There is also multissl_setup which is
> called by a bunch of multissl_ functions and not protected by a lock,
> for example multissl_getsock, multissl_close call it. That doesn't
> make a lot of sense to me. I've submitted a PR [1] that would protect
> the functions with a lock but I don't understand exactly why we need
> it if the user is using libcurl as intended. There are a bunch of
> functions that call multissl_setup after initialization, I don't know
> why though.
Of course, there can be other potential thread-safety problems around
multiSSL and your PR may have touched one. I'm not very comfortable with
the multiSSL code but I don't think this affects the curl_version_info()
problem. The latter cannot be resolved with a lock because it concerns
static data access by the caller.

Thanks anyway for looking at it!


Received on 2022-09-25