History of poll() API (was: Python recompile)

On Mon, 10 Mar 2025 19:26:58 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

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. 

 
3. Perhaps the underlying operating system under which select was
   initially developed (BSD2?) had a hard NFILE limit which
   matched FD_SETSIZE.   V7 had a fixed per-process  descriptor table
indexed by the file descriptor, IIRC.
 
 
I belive poll showed up in AT&T unix around SVR3, if I
recall correctly.
 
 

Original Winsock2 does not provide poll(). poll() (WSAPoll) didn't
become available on Windows until much later (IIRC, Vista, i.e. 13-14
years after original Winsock2 API specification).
I didn't find exact accounts in Wikipedia, but it seems that Winsock2
API is based on BSD4.3, probably with contributions from SunOS 4.
Is poll() available in BSD4.3 and/or in SunOS 4?