Sujet : Re: Python recompile
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 10. Mar 2025, 19:05:28
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250310110119.147@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-03-10, Scott Lurndal <
scott@slp53.sl.home> wrote:
Muttley@DastardlyHQ.org writes:
On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <already5chosen@yahoo.com> wibbled:
Similar to poll(), yes. Not so similar to super-ugly select(). I hope
that Unix people stopped using select in new programs two or more
decades ago.
>
Nothing wrong with select if you're not multiplexing hundreds of file
descriptors. Does the job.
>
>
The primary constraint for select(2) is not the _number_ of files
that can be selected amongst (although that _is_ a constraint),
but rather the largest file descriptor number is limited by the
select(2) bitmap interface (FD_SETSIZE not only defines the number
of file descriptors that can be passed, but also the highest
valued file descriptor that can be passed). poll(2) has no
such limits.
Indeed!
I think it would be fair to say that select was designed with
these assumptions:
1. The program's open file descriptors will be tightly clustered
next to zero, with few gaps.
2. The program will be polling almost all of those descriptors.
Scenarios were not envisioned such as that the program will have
lots of threads, many of which want to poll a small number of
descriptors allocated in their own context.
(A similar thing can be done with classic forked children: but forked
children can close all descriptors they don't care about, and compress
the ones they care about to be clustered close to zero.)
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca