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.html
