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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Przemysław Sobala via curl-library <curl-library_at_lists.haxx.se>
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
> <https://github.com/curl/curl/blob/master/docs/examples/multi-uv.c>,
> 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
<https://github.com/curl/curl/blob/curl-8_1_2/lib/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.
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
> <https://github.com/curl/curl/blob/master/docs/examples/multi-uv.c>,
> 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
<https://github.com/curl/curl/blob/curl-8_1_2/lib/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
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-06-05