On 14. 7. 25 01:08, Greg Stein wrote:
On Sun, Jul 13, 2025 at 2:32 PM Daniel Sahlberg
<daniel.l.sahlb...@gmail.com> 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 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.
>...
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.
The *original* vision for APR was "portable runtime". Deal with the
things that were different across platforms. Haul those differences
into a uniform API.
At some point, that got corrupted into "grab bag of utility APIs that
have nothing to do with portability" (think: database and LDAP APIs)
Using c-ares or unbound, as a configuration option makes more sense,
and means that we don't have to bounce our dependencies to a recent
APR. ... should the APR community want to build this in, then that
could be a third option for an async DNS resolver (c-ares, unbound, apr).
I'm +1 for anybody that wants to add async resolve into serf. That
"synchronous fault" is a very good point, Brane.
I have a proof-of-concept implementation, using apr_thread_pool for
faking the asynchronous bits. Needs some testing -- I'm going to splice
it into Subversion and see what goes BOOM when I do a checkout -- then
commit to trunk. I won't bother with a branch, it's really quite
self-contained, only minimally touches serf_context_t and
serf_context_prerun(), everything else is in a new file.
-- Brane
