[PATCH] Do not translate ENOMEM to EAGAIN in pthread_create

[Florian Weimer]

* Andreas Schwab:

> On Jul 08 2026, Florian Weimer wrote:
>
>> diff --git a/manual/threads.texi b/manual/threads.texi
>> index 0331599bc0..2f43f7f917 100644
>> --- a/manual/threads.texi
>> +++ b/manual/threads.texi
>> @@ -593,7 +593,27 @@ This function creates a new thread with attributes @var{attr}.  This
>>  thread will call @var{start_routine} and pass it @var{arg}.  If
>>  @var{start_routine} returns, the thread will exit and the return value
>>  will become the thread's exit value.  The new thread's ID is stored in
>> -@var{newthread}.  Returns 0 on success.
>> +@var{newthread}.  Returns 0 on success, and an error code on failure.
>> +Among the failure codes are:
>> +
>> +@table @code
>> +@item EAGAIN
>> +The thread could not be created because the maximum thread count for the
>> +process, user, or system has been reached.  On Linux, this error can be
>> +spurious, and calling @code{pthread_create} again may succeed although
>> +no threads have exited since the previous call.
>
> Perhaps s/although/even if/.

In general, I lean heavily towards “even if”, so I try to compensate.

>> +@item ENOMEM
>> +Memory for the new thread could not be allocated.  This can refer to
>> +memory for the stack, thread-local storage, or administrative data.
>> +
>> +POSIX suggests reporting these error conditions as @code{EAGAIN},
>
> I don't think it is a suggestion, but a shall.

What does this mean for glibc?  I think the proposed change is genuinely
useful to some applications like OpenJDK.

Thanks,
Florian