Subject: Re: reached select() limit

Re: reached select() limit

From: Leif Thuresson <leif.thuresson_at_foxt.com>
Date: Thu, 26 Jan 2017 16:41:20 +0100

Just remembered an quirk we used to do way back to over come a problem
with old solaris versions where the
stdio struct used a char for the file descriptor.
If you have control over the file descriptors you application is
creating you can push them to higher numbers with
   newfd = fcntl(orgfd, F_DUPFD, lowlimit);
leaving a range of low number file descriptors free to use for c-ares.
Yes it's ugly, but if nothing else helps...

/Leif

On 2017-01-26 14:32, daniel_at_poradnik-webmastera.com wrote:
> 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.
>>>
Received on 2017-01-26