Thank you for your response. 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. 1. is using the share interface <https://curl.se/libcurl/c/libcurl-share.html> the preferred option? 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?
-- best regards Przemysław Sobala On Tue, 30 May 2023 at 00:10, Dan Fandrich via curl-library < curl-library@lists.haxx.se> wrote: > On Mon, May 29, 2023 at 11:41:04PM +0200, Przemysław Sobala via > curl-library wrote: > > If I understand the documentation correctly, the HSTS cache is applied > to each > > curl easy handle and it's read and written on each easy handle open and > close > > action. > > I'd like to use the in-memory cache as reading and writing a cache file > on > > every easy handle is redundant in my opinion and can slow down my > service. > > 1. How can I configure the in-memory cache for easy handles in Multi > Interface? > > You're probably looking for the share interface: > https://curl.se/libcurl/c/CURLSHOPT_SHARE.html > -- > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html >
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
