[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMXh4bUEdBVOmp2g3EigLTNp+7VOGkvmUgS+jpe3DzDt6+qPuw@mail.gmail.com>
Date: Fri, 19 Jun 2026 09:31:16 -0300
From: Adhemerval Zanella <adhemerval.zanella@...aro.org>
To: libc-coord@...ts.openwall.com
Subject: Re: pthread_create and translation of errors to EAGAIN
On Mon, Jun 15, 2026 at 5:42 AM Florian Weimer <fweimer@...hat.com> wrote:
>
> We currently translate ENOMEM errors to EAGAIN because of the POSIX
> requirement to use EAGAIN if the “system lacked the necessary resources
> to create another thread”. However, EAGAIN may be a spurious error due
> to incorrect resource accounting in the kernel, while ENOMEM most likely
> is not. Some applications and frameworks wrap pthread_create in loops
> that retry (for a while/a number of times) if pthread_create fails with
> EAGAIN. Due to our error code translation, these retries happen for
> (original) ENOMEM errors, too, where they are pointless.
>
> Should we avoid the error code translation?
It makes sense to me, at least for Linux they map to different failure modes:
EAGAIN from clone/clone3 is the RLIMIT_NPROC / thread-count / pid-exhaustion;
While ENOMEM from stack mmap or clone indicates resource exhaustion,
(address-space exhaustion, RLIMIT_AS, vm.max_map_count, or couldn't allocate
the task struct / copy context)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
