On 13. 7. 25 21:30, Daniel Sahlberg wrote:
Den sön 13 juli 2025 kl 14:52 skrev Branko Čibej<br...@apache.org>:
On 13. 7. 25 12:40, Graham Leggett wrote:
On 12 Jul 2025, at 22:27, Branko Čibej<br...@apache.org> 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.
Definite +1.
I had good results integrating unbound[1] into redwax-tool[2], which
has an async element that triggers a DNS lookup that in turn triggers
an SSL client connection. All of this is APR based.
I am keen to see APR(util) support platform independent async DNS, so
that blocking DNS calls aren't the default everywhere.
Putting the async DNS bits into APR has also crossed my mind. It would
certainly be more visible there than in Serf.
I think it depends a bit on how much this would change the API in APR.
It feels like a good idea to add this to APR, since it might be useful for
other projects as well.
Yes. This would be an entirely new API, you can't magically change
something that's synchronous into something else that is not, without
radical API changes.
But if it would require APR to grow a new API that is more or less just a
translation layer for c-ares' or ubound's API and we would anyway have to
build support for this new API in Serf, then it probably makes more sense
to add this directly to Serf.
Ideally, the DNS resolver would act like "just" another connection
that's handled by the context loop. The implementations I've been
looking at (and there aren't that many) rely on callbacks to the client
to return results. We can handle something like that in Serf.
On the other hand I don't have a strong feeling about this so I'll leave
that up to whoever wants to have a go at implementing this.
It boils down to this: if it's in APR, more projects can use it (e.g.,
HTTPd with mTLS and OCSP validation is one such possible use case). If
it's in Serf, well, right now it will only be used by Subversion.
I don't really care where this happens, but I've been badly bitten by
synchronous DNS lookups -- essentially I had to create a separate thread
pool for DNS lookups with callbacks into the main context loop. It
works, but one shouldn't have to do that.
-- Brane
