Subject: Re: reached select() limit

Re: reached select() limit

From: David Guillen Fandos <david_at_davidgf.net>
Date: Thu, 26 Jan 2017 21:06:08 +0100

My program mostly opens sockets, the responsible for fd starvation. If I
create a socket and move it above 1024, and as log as I don't have, say
200 threads creating sockets, I can't run out of sockets under 1024
right? For that to happen all the threads would need to be after the dup
and before the close, that means I should have less than 512 threads right?
Well in my case all sockets are created in the same thread so no worries
about that

Thanks!

On 26/01/17 20:56, Zan Lynx wrote:
> On 1/26/2017 11:40 AM, David Guillen Fandos wrote:
>> Genious! I didn't know about that thing!
>> So you just dup the fd and close the old one right?
>>
>> Thanks!
>> David
>>
>> On 26/01/17 16:41, Leif Thuresson wrote:
>>> 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
>>>
>>>
>
> It is possible for this to have a race condition in threaded programs if
> your other threads are opening new sockets faster than they can be moved
> to the high range. It's unlikely but make sure the code still has a
> <FD_SETSIZE check before putting a FD into a select bitmap.
Received on 2017-01-26