0

Recent POSIX tells me that an fd_set is a structure capable of holding up to FD_SETSIZE fd's.

On Linux and glibc I find that FD_SETSIZE is 1024, the default (soft) RLIMIT_NOFILE is also 1024, and sysconf(_SC_OPEN_MAX) is also 1024.

I can increase the RLIMIT_NOFILE, but I cannot find anything in POSIX which tells me how to create an "extended fd_set" to match the new maximum number of fd's.

It looks like older POSIX used to specify that the fd_set contained an array fds_bits, and it would then be safe to create an "extended fd_set" as some multiple of sizeof(fds_bits[0]) (suitably aligned).

I find that various BSDs allow me to set FD_SETSIZE, provided that's done early enough. That doesn't seem to work for glibc and Linux :-(

It seems that NFDBIT is perhaps what I need -- which is a BSD thing, which glibc will give me under __USE_MISC. There is also an fd_mask type, where the bit vector is fd_mask xxx[xx].

What I cannot find is a POSIX way to do this. Have I missed something ?

I know that for thousands of fd's I should probably be using epoll or kqueue... but I feel there should be a standard way of extending fd_set beyond FD_SETSIZE.

Chris Hall
  • 1,707
  • 1
  • 4
  • 14
  • `FD_SETSIZE` and `RLIMIT_NOFILE` are orthogonal. – Maxim Egorushkin Dec 08 '20 at 12:58
  • 2
    Relevant question: https://stackoverflow.com/q/7976388 . I would really suggest that you use epoll/kqueue though (whether directly or through a wrapper library). – Hasturkun Dec 08 '20 at 13:00
  • @MaximEgorushkin: indeed... and it's a trap for the unwary -- just because some form of 'open' has returned an `fd` doesn't mean you can `FD_SET(fd, xxx)` :-( – Chris Hall Dec 09 '20 at 14:17

0 Answers0