musl - ENOFILE after reaching SEM_NSEMS

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <2dcdd7436bd07e0b020644fac1b3a06256db8673.camel@prauscher.de>
Date: Mon, 08 Jan 2024 15:01:46 +0100
From: Patrick Rauscher <listen@...uscher.de>
To: musl@...ts.openwall.com
Subject: ENOFILE after reaching SEM_NSEMS_MAX

Hello everyone,

in POSIX, the constant SEM_NSEMS_MAX is defined as 256 from some time. While
glibc nowadays ignores the limit and will yield -1 when asked for it [1], musl
currently will return ENOFILE when asking for the 256th semaphore.

This hit me (and obviously another person) when using python multiprocessing
[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 note
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 🙂

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-file-descriptors-available-error-inside-docker-alpine

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.