X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A38493858C39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1657120065; bh=SXF4o+qw3xyPCV+b37eYV3sa/sg9z4uDYEpzxfx7ARM=; h=Date:From:To:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Reply-To:From; b=xpsLg3zoCJe4JsqvuxYgRZFPtpLTM8Hr2kuvHABdl3gKC1ALjT3r5TM9akUyYlPYM 0hWNBHp7xfcQuLRjlJeZgJpAim2GNahPErNfdyaBDRo+wTHR5BnKqZgbwBCrGtY4qb b0bviFTqiOmUVSAhZ+qDVgBLJ3maBlogVrqQAGDI= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com 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 Date: Wed, 6 Jul 2022 17:07:14 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Typo in ? Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Disposition: inline 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 AT cygwin DOT 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: , Reply-To: cygwin AT cygwin DOT com Content-Type: text/plain; charset="utf-8" Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 266F7mmX025153 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