It’s faster than poll, and if you are accept()ing a lot, faster than epoll.
Multiple threads can do better, but only by working together. SO_REUSEPORT+select is faster if you can get away with it. Iouring looks promising though.
> Using it assumes the execution environment keeps all file descriptor values within FD_SETSIZE.
That’s what the rlimit is for. If you call a program that uses select with 1025 open FD you get what you deserve.
I thought that FD_SETSIZE was a compile-time constant that limited what values for file descriptors could be passed to select.
IOW, it doesn't matter if you have only two files open; if one of them has an fd with a value of 1026, then select will do the wrong thing.
The Linux syscall does not have a fixed FD_SETSIZE so glibc could increase the size.
This is exactly correct.
> The Linux syscall does not have a fixed FD_SETSIZE so glibc could increase the size.
The application writer can define FD_SETSIZE before including <sys/socket.h> and set it to whatever they want on BSD (including OSX). glibc could* adopt this trick, but my feeling is you probably don't want to stack-allocate this stuff anyway.
Dealing with a large number of very-active connections concurrently efficiently requires more effort than just this though.
A compatibility hack for some applications reliant on badly-done select() might be to set RLIMIT_NOFILE to FD_SETSIZE.
Of course you can.
dup2(0,1026)It's more than promising. It's an unbridled joy to work with (compared to things like epoll) and performs very well already.