DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D4653858C20
Date: Wed, 6 Jul 2022 17:07:14 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Typo in <sys/select.h>?
Message-ID: <YsWlIkz7QTwSK9g1@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <DM8PR09MB709506526ACE1ACB3E0E41F3A5809@DM8PR09MB7095.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DM8PR09MB709506526ACE1ACB3E0E41F3A5809@DM8PR09MB7095.namprd09.prod.outlook.com>
Precedence: list
Reply-To: cygwin@cygwin.com
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

On Jul  6 14:26, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > DESCRIPTION
> >        WARNING: select() can monitor only file descriptors  numbers  that  are
> >        less  than  FD_SETSIZE (1024)-an unreasonably low limit for many modern
> 
> Whoever wrote this, was wrong (they might have never consulted the actual kernel code, or were just
> blindsided by FD_SETSIZE being a predefined constant).  You can take a look at the kernel source code,
> if you don't believe me.
> 
> This select() trick has been like that from the earliest days of Linux, and the behavior is carefully carried over.
> 
> https://github.com/torvalds/linux/blob/master/fs/select.c#L625
> 
> It's just an FYI :-)

:+1:

You're right as far as the kernel is concerned.  The problem is apparently
in glibc.  From the same man page:

  POSIX allows an implementation to define an upper limit, advertised via
  the constant FD_SETSIZE, on the range of file descriptors that  can  be
  specified  in a file descriptor set.  The Linux kernel imposes no fixed
  limit, but the glibc implementation makes  fd_set  a  fixed-size  type,
  with  FD_SETSIZE  defined  as 1024, and the FD_*() macros operating ac‐
  cording to that limit.  To monitor file descriptors greater than  1023,
  use poll(2) or epoll(7) instead.

And that's still the case with glibc from current git master:

bits/typesizes.h:

  /* Number of descriptors that can fit in an `fd_set'.  */
  #define __FD_SETSIZE            1024

That's defined unconditionally, just as this stuff from sys/select.h:

misc/sys/select.h:

  /* fd_set for select and pselect.  */
  typedef struct
    { 
      /* XPG4.2 requires this member name.  Otherwise avoid the name
	 from the global namespace.  */
  #ifdef __USE_XOPEN
      __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
  # define __FDS_BITS(set) ((set)->fds_bits)
  #else
      __fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS];
  # define __FDS_BITS(set) ((set)->__fds_bits)
  #endif
    } fd_set;

  /* Maximum number of file descriptors in `fd_set'.  */
  #define FD_SETSIZE              __FD_SETSIZE

However, discussing this shows how irrelevant the actual default value
of FD_SETSIZE is.  Per POSIX, it's just that, a default value.  In
interested process which thinks it needs higher fd numbers should make
sure to define FD_SETSIZE according to its requirements anyway.


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple