From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1184 invoked from network); 8 Jan 2024 14:02:06 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Jan 2024 14:02:06 -0000 Received: (qmail 32477 invoked by uid 550); 8 Jan 2024 14:00:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32439 invoked from network); 8 Jan 2024 14:00:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prauscher.de; s=mail-202312; t=1704722512; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=NIlHnnuP2fEFwXYeGmAID4GtRup7DINGN9I3cyol/oE=; b=0qzcUh8FjKubws2rDcKAoiHqfIDFSLW/Al9mVlPseWxSg42nD38+a+qkkR2MvUEcM+IJgt 8LRJp0z9T2cN3e/Yps04dpB2v+l7+uubUNDzqhjcIjJ871mdFskhQ1UtG5tlj3n13noic7 PXGsL5HhRfBHoptlFVlkHq2o9p2UpbhBebEG4W8sE+NMpWJzG5eoPki5H37hCaCE2FHPVf jrsYCXy3ZpDlYBx2Mse5qjAkTLjNPiOlfnBMGj3pJSq6blC8EY9qTStCXK7SWBM1//cEha MVkMpYal71upI8P8pFDPqGPMsoJkOGLcBSNmU6wCRKfOnG1oLiRYFWMC6yLsCA== Message-ID: <2dcdd7436bd07e0b020644fac1b3a06256db8673.camel@prauscher.de> From: Patrick Rauscher To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 08 Jan 2024 15:01:46 +0100 MIME-Version: 1.0 User-Agent: Evolution 3.50.2 Subject: [musl] ENOFILE after reaching SEM_NSEMS_MAX Hello everyone, in POSIX, the constant SEM_NSEMS_MAX is defined as 256 from some time. Whil= e glibc nowadays ignores the limit and will yield -1 when asked for it [1], m= usl currently will return ENOFILE when asking for the 256th semaphore. This hit me (and obviously another person) when using python multiprocessin= g [2]: Jan H detected, that while allocating a large number of semaphores (or objects using at least one semaphore) works on Debian, it fails on alpine. Thanks to psykose on the IRC the issue could be identified to the different libc. To make this finding less ephemeral than on the IRC log, I leave a no= te here. As sem_open works in the documented way, this is certainly no bug report, rather a feature request if you will so. Due to my lack of C-knowledge I may only standby and marvel to further discussion, but maybe someone can come up with ideas =F0=9F=99=82 Thanks for your time, Patrick 1: https://sourceware.org/legacy-ml/libc-help/2012-02/msg00003.html 2: https://stackoverflow.com/questions/77679957/python-multiprocessing-no-f= ile-descriptors-available-error-inside-docker-alpine