Re: Python recompile

On Tue, 11 Mar 2025 20:52:19 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:

On Tue, 11 Mar 2025 08:34:43 -0000 (UTC), Muttley wrote:
>

On Mon, 10 Mar 2025 21:38:35 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>
the numbers of those FDs lie beyond the upper limit of the array, you’re
stuffed.

>
Any descriptor created that had a value greater than select() could cope
with would break a lot of old code so although I have no proof, I'd bet
money on the kernel/libc authors taking this into account when
allocating user space descriptor values.

>
You really want to bet money? From
<https://manpages.debian.org/select(2)>:
>
   BUGS
>
   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 according to that limit.
>
Default settings on my current system:
>
   ldo@theon:~> prlimit -n
   RESOURCE DESCRIPTION              SOFT   HARD UNITS
   NOFILE   max number of open files 1024 524288 files
>
How much are you going to pay?

Nothing, because who knows what libc will do if the descriptor exceeds
that soft limit. It may try again to get a lower value.