Re: reached select() limit

On 01/31/2017 07:28 PM, Zan Lynx wrote: On 01/31/2017 06:41 AM, eugeny gladkih wrote: no, that's not a truth. you may use any socket number on all modern UNIX systems. the only thing you need - you have to allocate enough memory for fd_set. one more thing you have to know is still here. on

Re: reached select() limit

Yep, I think glibc related functions might be using some compile time information (like sizeof or #defines) so I wouldn't date to try that :D Thanks! 2017-01-31 17:28 GMT+01:00 Zan Lynx : > On 01/31/2017 06:41 AM, eugeny gladkih wrote: > > no, that's not a truth. you may use any

Re: reached select() limit

On 01/31/2017 06:41 AM, eugeny gladkih wrote: > no, that's not a truth. you may use any socket number on all modern UNIX > systems. the only thing you need - you have to allocate enough memory > for fd_set. one more thing you have to know is still here. on Solaris > you may define the FD_SETSIZE

Re: reached select() limit

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,

Re: reached select() limit

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

Re: reached select() limit

Why is 16 too few? Do you have more than 8-16 name servers configured? Remember, it is one fd per nameserver (or possibly 2 if it has to fall back to TCP), NOT one fd per query, as my original reply stated. The ares_getsock is what you'd use, and yes, it does have a limit of 16 fds. -Brad On

Re: reached select() limit

Thank you for reminding me about the select() limit's relationship to FD_SET. I had forgotten that. My quick answer about setrlimit() was based on a binary I worked in that used c-ares plus numerous other socket-oriented libraries. I ran into the FD_SET problem in my other socket-dependent

Re: reached select() limit

On January 24, 2017 7:16:35 PM MST, Daniel Hardman wrote: >Your program should call setrlimit on startup to change the number of >file >descriptors. See http://unix.stackexchange.com/a/29579. > > That will not help because select has a hard coded limit of the number

Re: reached select() limit

David is correct, on many systems, like Linux, select() cannot handle file descriptor *numbers*, higher than 1023 (most people assume it is just the count of fds set via FD_SET cannot exceed 1024, which is also true). Since he stated he is working with fds higher than that, it is presumed his

Re: reached select() limit

I'm pretty sure c-ares just uses a single socket per nameserver, so to have more than 16 socks, you'd have to have more than 8 DNS servers (I'm assuming here that each server tries both UDP, then due to response overflow has to retry via TCP). I use c-ares with an event based system where we use

reached select() limit

Hello, I wrote an app that was crashing in c-ares due to fds being bigger than 1024. While c-ares might be using around 30 fds it is unable to use fds above 1024. I looked into using getsock but it is capped at 16 sockets (although could be worked around by building c-ares myself and