Ha! That's awesome, exactly what I was looking for. Thanks a lot Daniel! David
2017-01-26 14:32 GMT+01:00 <dan...@poradnik-webmastera.com>: > You can also register callbacks using ares_options::sock_state_cb and > ares_set_socket_callback(), which simplifies things a lot. I used them when > I was integrating c-ares with our epoll-based code. > > Daniel > > > W dniu 2017-01-25 18:48, David Guillen Fandos napisaĆ(a): > >> Ha! >> >> Sorry for that, I just realized that it returns a bitmap of sockets. >> Why doesn't it return something like uint32_t? >> >> Allright then, so there's really no way to workaround my problem >> except, perhaps, to initialize c-ares at the begining of the process. >> But c-ares doesn't guarantee that all fds are gonna get created at >> start right? If some server doesn't respond it might try TCP and open >> a new socket, am I right? >> >> Thanks for your help! >> David >> >> On 25/01/17 15:17, Daniel Stenberg wrote: >> >>> On Wed, 25 Jan 2017, David Guillen Fandos wrote: >>> >>> Yeah agreed, but how do you retrieve the fds to use poll? With getsock >>>> you get up to 16 sockets which is insufficient for my needs (and also, >>>> BTW, sounds like an arbitrary and ridiculous number to hardcode in >>>> such a function) >>>> >>> >>> Arbitrary? Not really, it happens to be the number that fits in an >>> unsigned 32bit variable as each socket needs two bits in the API. I just >>> considered it a dececently convenient API at the time (and happens to be >>> similar to a function interface we use internally in libcurl). >>> >>> Ridiculous? Maybe, but I added that API a long time ago and I have yet >>> to end up in a case where the 16 limit has been reached and impacted us >>> (or anyone else). I added this API to allow libcurl to use c-ares >>> event-based and we've since used it with many thousand simultaneous >>> requests and DNS looks with success - over the period of many years. >>> >>> Can it be improved? I'm sure. >>> >>>