Subject: Re: [Patch] An alternative to ares_fds() and ares_getsock()

Re: [Patch] An alternative to ares_fds() and ares_getsock()

From: John Bäckstrand <sandos_at_home.se>
Date: 2006-02-10

Brad Spencer wrote:
> Ok, first off, I'll admit that I am using c-ares-1.3.0 and didn't
> notice that what is to become 1.3.1 already has a new function called
> ares_getsock(). But even after seeing that new function, I thought
> I'd post my patch with yet another way to get file descriptors and see
> if it generated any discussion.
>
> I think the aim of ares_getsock() is to avoid having to write one
> accessor for poll(), one for select(), one for epoll (my personal
> choice), and so on. I actually use asynchronous single-threaded C++
> most of the time, so I actually have an object that manages my epoll
> calls for me, and it's interface is essentially watch(fd, eventFlags)
> and ignore(fd, eventFlags), and it's smart enough to not do anything
> if it's already doing that. Enough background.

I'm using libevent and I do a very ugly hack to get the fds out of ares,
  create one ares_channel per lookup, and then I use ares_fd() to get
the fd of this single socket and newly created lookup, which I then let
libevent handle, along with all my other sockets. This does not work
very well though, and Im not even sure why, I havent been able to track
the cause down. Anyway, just wanted to chime in on the fact that, too,
want a way to get at the fds and use something other than select. I
would love for c-ares to use libevent itself ;)

Btw, could you (or anyone else?) let me look at any example source where
you handle the I/O abstraction for c-ares with something other than
select? I would very much appreciate it.

---
John Bäckstrand
Received on Fri Feb 10 23:09:33 2006