Yeah but fds are guaranteed to be opened lowest available on first, so thats ok, you cant get fd=1026 without having 1026 open.
The Linux syscall does not have a fixed FD_SETSIZE so glibc could increase the size.
The Linux syscall does not have a fixed FD_SETSIZE so glibc could increase the size.
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)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.