async dns
14 points by runxiyu
14 points by runxiyu
Seems a bit odd that the author is looking at async APIs, but complains about having to use callbacks or select/epoll or event loops. Dude, how else do async C APIs work? Then the one they like requires you to manually poll waiting for a result to appear, which is the worst option.
I don't think he's complaining about callbacks per se, more that the c-ares callbacks are a crufty mess.
Back in 2010 I got interested in DNS, and I wrote a library to encode/decode DNS packets. I got hired by a company around this time, and learned that two separate projects were attempting to integrate c-ares into event-driven servers. Both teams had been spending over a month attempting to get it working. I pointed out my library, and within a day, both projects got DNS resolution working (mainly because all I provided was DNS encoding/decoding, leaving the network layer alone).
I think if you don't have an event loop, c-ares might very well work for you. If you do have an existing event loop, then probably not.
If your existing event loop is based on select it also integrates very well with that.
Why would waiting for an event on an fd be the worst option? You can slot it into any event loop you want, use any of the file status notifications -- poll, kqueue, select, io_uring, or even just a blocking read() if you want, and it ends up being less code than the libraries that try to do more.
It’s not a fd, unless I’m misreading. They say “ It’s very much like read or write in that it either gives you an answer, or tells you to come back later, and then it’s up to you to decide when that is.” Which sounds like manual polling to me.