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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
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!
Patrick
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!
Patrick
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-25