curl / Mailing Lists / curl-library / Single Mail


Re: Global lock for lazy PSL loading ?

From: Tim Ruehsen <>
Date: Wed, 14 Dec 2016 15:01:25 +0100

On Tuesday, December 13, 2016 2:51:07 PM CET Daniel Stenberg wrote:
> On Mon, 12 Dec 2016, Tim Ruehsen wrote:
> > I would like to improve the PSL code in Curl_cookie_add(), namely use
> > psl_latest() instead of psl_builtin() if possible.
> >
> > That function eventually introduces (local) loading of the latest
> > available
> > PSL data (either DAFSA or plain text PSL). So I think of a static/global
> > psl_ctx_t variable, that will be lazy- initialized on the first call to
> > Curl_cookie_add().
> >
> > That needs a global locking function... well, what do you suggest ? [I am
> > pretty sure that Curl_share_lock() is not the solution (might result in
> > several one PSL loading per Curl_easy instance), but didn't find a better
> > function yet.]
> This is an interesting problem.
> libcurl doesn't have a lock function for global context. It was designed to
> not have any global context. The only way we _can_ add or init global
> context right now is in the curl_global_init() function which is explicitly
> documented to not be thread safe - but we need to still be careful since
> this fact is often overlooked by users and we don't want to hurt those more
> than necessary.
> The locking functions are in the share APIO because that's the way users can
> opt to share data between easy handles.
> A common pattern within libcurl is to keep data in the multi handle and
> share such data with the participating easy handles, which requires no
> locking. That's still not a global context of course.
> Then finally: do we really want to add another uncoditional file load (even
> if only at first use)?

Most people using cookies are not aware of the PSL, so a first load here could
make sense. The DAFSA format requires no parsing or relocations, just a read/
mmap of ~33k (very slowly growing with PSL updates).

> Maybe we want to let users decided that anyway?

This is another possibility and a good decision for long-running processes.
These could eventually unload/reload the PSL from time to time.
Such an API should be cross-referenced/promoted from the existing cookie API

/* int Curl_psl_load(struct Curl_easy *data, const char *file) */
int Curl_psl_load_default(struct Curl_easy *data)
void Curl_psl_unload(struct Curl_easy *data)

Curl_psl_load_default() does the best it can, takes the newest file / data
available, corresponding to psl_latest() from libpsl 0.16.0.

Since people normally do not hassle with their own copy of the PSL, I would
leave away Curl_psl_load() for now.

Give me a word if / how you like that (or how you decide) and I'll implement
it when I find the time.

Regards, Tim

List admin:

Received on 2016-12-14