Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastardlyHQ.org
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Wed, 12 Mar 2025 08:11:45 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <vqrfk1$2gqoc$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq4m0u$1ctpn$1@dont-email.me>
	<vq4n05$1d5dv$1@dont-email.me> <vq4om7$1dbo2$2@dont-email.me>
	<vq6dqh$1pskk$1@dont-email.me> <vq6f8p$1pmnk$1@dont-email.me>
	<vq6gqc$1qcp8$1@dont-email.me> <vq6ips$1pmnk$2@dont-email.me>
	<vq6j5h$1qosf$1@dont-email.me> <20250304092827.708@kylheku.com>
	<vq7g1p$1vmg5$1@dont-email.me> <vq94dt$2boso$1@dont-email.me>
	<vqcsk7$23bfo$1@paganini.bofh.team> <vqefn1$3flpt$1@dont-email.me>
	<vqeu5c$3imil$1@dont-email.me> <vqeun4$3iqbq$1@dont-email.me>
	<vqfcbe$3lkkc$1@dont-email.me> <871pv861ht.fsf@nosuchdomain.example.com>
	<20250308192940.00001351@yahoo.com> <vqi1ge$8jg8$1@dont-email.me>
	<vqibt3$ahu0$3@dont-email.me> <vqiibq$bq1o$7@dont-email.me>
	<20250309012626.00001276@yahoo.com> <vqiugc$dv5o$2@dont-email.me>
	<20250309112807.0000489d@yahoo.com> <vql2bf$uei7$2@dont-email.me>
	<20250310152000.00004955@yahoo.com> <vqmvei$1dhpg$1@dont-email.me>
	<vqnm4r$1i1s0$5@dont-email.me> <vqosj3$1spcv$1@dont-email.me>
 <vqq7q2$25gtn$4@dont-email.me>
Injection-Date: Wed, 12 Mar 2025 09:11:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="dad2c687b964bd996f7e93d44f6261e5";
	logging-data="2648844"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189THBlhU9I9Evwuw35AFuo"
Cancel-Lock: sha1:vKYvx+osWgYqweTFB2cr6iFMtQ4=

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.