On 16. 7. 25 22:03, Daniel Sahlberg wrote:
Den tis 15 juli 2025 kl 23:07 skrev Branko Čibej<br...@apache.org>:
r1927249. Please review; I haven't tested with Subversion yet.
I'm thinking that this implementation can stay as a fallback if there is
no unbound/c-ares/whatever available. It works, though it's not the most
blazingly efficient way to do this. It would be a pity to disable the
API just because of some missing optional dependencies.
I've looked but I think it is a bit over my level of experience to really
review, sorry.
Have you checked if the proposed API would make sense for unbound/c-ares?
Yes, I have, of course. It may not be 100% there on the implementation
end, that would be validated by a real integration. But the public API
is pretty solid, IMO. Well, apart from naming and other minor nits. :)
Probably a good idea to keep the APR-thread based implementation - maybe
that would even be enough (at least for a start)? Or is it missing
something?
Apart from the notes I left in src/resolve.c, it's fine. Yes, I'd
certainly keep the thread-pool based implementation as a fallback. As I
wrote above, it doesn't make sense to disable the API because of a
missing optional dependency. It does depend on APR_HAS_THREADS, but,
frankly, I can't see how this could be a real issue.
-- Brane
