LTDR; don't?

Hi,

I'm reorganizing how Libreswan performs DNS.   The old code would either:
- used ub_resolve() in a separate process
- used ub_resolve_event() in the IKE daemon
Since the new code will all live in the IKE daemon I need to revisit
how unbound is being used.
(the IKE daemon has a main thread running an event-loop (libevent),
and a thread pool to perform crypto)

With that in mind, I've a few things I'm not clear on.

- given a single context, can it be passed to any of the three calls
ub_resolve{,_async,_event}()
I'm fairly sure that a context created with ub_ctx_create_event() must
only be passed to ub_resolve_event(); however I'm less clear about a
context created using ub_ctx_create() being passed to both
ub_resolve() and ub_resolve_async().
But I suspect the answer is still "don't do that".

- given a single context, can it be passed to ub_resolve() (the
blocking variant) from different threads?
Just asking.  There's a comment saying "Application not threaded", so
probably not.

- is the lookup cache per-context, or shared between contexts?
If it's per-context, the argument for reworking the ub_resolve() calls
and have everything share a single context becomes stronger

- the ub_resolve_async() code creates and uses a libworker_bg() thread
that does the heavy lifting (talk to internet, DNSSEC math)
Is there one thread per context, one thread per resolve request, or ...?

- for ub_resolve_event() does the heavy lifting (notably DNSSEC math)
happen on the main thread or worker threads?

Anyway, I suspect my strategy is to change the code to use
ub_resolve_async() with its single worker.

Andrew

Reply via email to