From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by sourceware.org (Postfix) with ESMTPS id 2D4653858C20 for ; Wed, 6 Jul 2022 15:07:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D4653858C20 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MEmAX-1oOlwH2vUZ-00GGpn for ; Wed, 06 Jul 2022 17:07:14 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 423E8A80A3C; Wed, 6 Jul 2022 17:07:14 +0200 (CEST) Date: Wed, 6 Jul 2022 17:07:14 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Typo in ? Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Provags-ID: V03:K1:rg988xb7eNhWHz+e1qlhli2Co8AZFREJ/lxySb0pHSi99wtiLVL YdT83B+0pHQGW9HT2ZLusIhyHKPYe12UVRDFiwkRUqRCBhIfJpPi4V3rLRZsK6vazYYus3+ W06raCWPHXcIfYpyG0L6FD8ERAHYvgUxoQzGQ0DBxPisbagHlpr7WLA2qnLPUE0zjGf4x6/ dQUl5uwjqgmU8ZzztLKDw== X-UI-Out-Filterresults: notjunk:1;V03:K0:3ETc3OWE8wU=:BxIjUOTAex3qZLC3q8CIGo iPyKUOa0gLgHHdejtBYAipkP/Zri8moEi1O8/+//Ck/dJrOm5xHYlof6X9+l2ZSGmpGstuY7q O40wTfZdOPQjAwUSiKGaCP8fjOtnxQkqleZkf7ZI/iw7g76AKFlrvpRI0u3dgw4PyePyT5pXJ uBIUwuyKM+j5Y4lO0ub0IW1aSIy9AcodcUp9QM91h3CSiSm2Wq9CrKUFzskXMQeyOkdrfHIZi 9Wp0rTsfjI820pbuVbENUa63ACRxlsohiO4ck9UXh26L82LEdhvv7wWc04RFFTDgbxnnLXPkK 3SwlO2U+NSGx1AL80xFciPx+hY8aJaHj1aGHmITdOHHj9dcLJdhqOBEabzcTA5zgQ17Beo0HP 2MTU+0tCA7/xpaTJxaUV0g+kMkroDgxgM8zqiFI60nAgWOXkn6wl39viUY72d2vuwfd99vOi1 ss8eijcy1GEPO4h1S6gXe7tT4J6DC9G/OPUysKuAqEXlSGNtgIdiwPOSWB3GgISARezztL3Ap WPeJd+M3CCshYedhHfg48SWB0gubMNPZY7rtB3jSC1XIywQA+vZKAKj5LIpmG8tvS3HOMNXga VpmCXkliIC92Z1s4i+P8Zq4cofNn3JsVxgWrvH8gOom8H+ULNRrqD7sPvcP0qaKbWooscMBdl iswXzdrBCpDUdgxNTt9TRo+ael1+rh/8gPvei0ckzXtXIGBMnHxG/kUODs3eoDA031Ed67ATH dDZublEka6s2l4Z2+eD4uMiS1UVTrRgF/qt/aDK/LvdAyB6HUJnNmw6T96U= X-Spam-Status: No, score=-95.0 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, SPF_FAIL, SPF_HELO_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2022 15:07:17 -0000 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