On 12. 7. 25 23:27, Branko Čibej wrote:
So, years ago, around the time I was adding the OCSP verification bits
to Serf, I integrated Serf into a system that used libdispatch.
Libdispatch does not like blocking code, at all, so Serf was close to
being na ideal fit.
Except for DNS lookups, which are synchronous and blocking. This
messed up the implementation quite a bit, especially with OCSP
verification thrown in the mix.
So here I am, 10 years later, throwing this proposal in the mix: Let's
make Serf truly asynchronous by getting rid of the blocking name
resolver. By "getting rid of", I mean adding support for an
asynchronous replacement such as, for example, c-ares. The real
culprit is actually APR with its blocking resolver calls, but it
shouldn't be too hard to work around that apr_sockaddr_info_get.
Thoughts? I'd be interested in putting in the work to make this
happen. I would not be interested in implementing a DNS client in Serf.
Serf has an asynchronous resolver now. If Unbound is available, it will
use that, otherwise (if APR_HAS_THREADS) it'll fall back to an
implementation that uses apr-util thread pools.
There are two new public APIs (each with a callback type):
* serf_address_resolve_async() is the interface to the resolver.
* serf_connection_create_async() asynchronously resolves the requested
hostname and creates the new connection in the given context when
that's done.
The implementation is in src/resolve.c.
There are some open issues:
* The resolver doesn't wake the serf_context_run() poll when it
receives a result. This is a bit tricky because, although APR has
serf_pollset_wakeup(), it doesn't work on all platforms. Perhaps we
can just use this and fix the platform support in APR, the
unsupported platforms are quite obscure.
* There's no asynchronous variant of serf_listener_create(). Do we
need one?
* We should probably remove serf_onnection_create3() from the public API.
Feedback welcome.
-- Brane
