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: multi interface with hsts cache

From: Przemysław Sobala via curl-library <>
Date: Mon, 5 Jun 2023 15:33:13 +0200

W dniu 5.06.2023 o 11:52, Przemysław Sobala pisze:
> Let's say I want to drop my cache preloading/dumping requirements and
> just use the in-memory HSTS cache shared between cURL easy handles,
> managed by the multi interface.
> 2. if so, and if my application receives tons of concurrent download
> requests and it's built on libuv and cURL's multi interface
> <>,
> should I introduce any locking mechanism while accessing the shared
> in-memory HSTS cache? I'm asking this question because libuv creates a
> single thread to manage all I/O operations and maybe because of that I
> don't need any additional locking?

I've just checked that the thread calling the HSTS in-memory cache write
and read functions in hsts.c
<> is the libuv
loop event thread, so the calls will never be executed concurrently. As
for that, I don't think I need any locking mechanisms and it would be
enough to add:

curl_easy_setopt(curl_easy, CURLOPT_HSTS_CTRL, CURLHSTS_ENABLE)
curl_easy_setopt(curl_easy, CURLOPT_SHARE, curl_share)

to every new easy handle.

best regards
Przemysław Sobala

Received on 2023-06-05