In article <[email protected]>,
...

select/poll is the one way to do event-driven programming.
There are other ways. In particular, under Windows you can
simultaneously wait for multiple objects with API that is called...
Surprise! WaitForMultipleObjects.
Yes, it does not work directly with anonymous files. But anonymous file
can be treated as a special version of named pipe and then it does work.

If it's not enough, I would guess that if one wants ultimate
scalability, one can force named pipes into working with I/O completion >ports, which is as scalable as one could wish.

But all that irrelevant.
What is relevant is that those things are used in sorts of POSIX
programs that I don't want to run either under cygwin or under msys2.
And for POSIX programs that I do want to run msys2 is simply better.

What language was this originally written in before it was fed to Google translate?

--
If you don't have faith, it's because you are reading the Bible with an
honest, truthful, real-answer seeking heart.

- Rick C Hodgin -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Mar 2025 19:26:58 GMT
[email protected] (Scott Lurndal) wrote:

Kaz Kylheku <[email protected]> writes:

On 2025-03-10, Scott Lurndal <[email protected]> wrote:

[email protected] writes:

On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> 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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <[email protected]> writes:

On Mon, 10 Mar 2025 19:26:58 GMT
[email protected] (Scott Lurndal) wrote:

Kaz Kylheku <[email protected]> writes:

On 2025-03-10, Scott Lurndal <[email protected]> wrote:

[email protected] writes:

On Mon, 10 Mar 2025 15:20:00 +0200
Michael S <[email protected]> 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?

poll() came from system V.

While it is part of FreeBSD, I'm not sure when it was added to the
original BSD distribution. It wasn't part of BSD2.

System V originally developed their own network interface (based on
streams in SVR4) but later adopted the bsd socket interface.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <FkYzP.991250$[email protected]>,
Scott Lurndal <[email protected]> wrote:

Michael S <[email protected]> writes:

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?

poll() came from system V.

While it is part of FreeBSD, I'm not sure when it was added to the
original BSD distribution. It wasn't part of BSD2.

Looks like it came into FreeBSD in 1997, by way of an
implementation in NetBSD. I thought perhaps it came via the
iBCS2 emulation, but that does not appear to be the case.

In the NetBSD tree, mycroft codified and exposed it in 1996. A
glance at the change suggests it was merging SysV interface and
the SunOS version, presumably these existed for binary
compatability with iBCS2 on i386 and SunOS on SPARC,
respectively.

I don't know when SunOS got it. I assume they picked it up from
System V.

System V originally developed their own network interface (based on
streams in SVR4) but later adopted the bsd socket interface.

Looks like it dates from SVR3. It's not in Bach, but that's
mostly SVR2.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vqq7q2$25gtn$[email protected]>,
Lawrence D'Oliveiro <[email protected]d> wrote:
...

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?

I'm sorry. I must have missed something.

This has ?what? to do with recompiling Python (*) ?

(*) That's the label you put on your post, so I assume you intend it to
have something to do with what you wrote in the label.

--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.

- John Kenneth Galbraith -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)