Re: Python recompile

On Mon, 10 Mar 2025 15:20:00 +0200, Michael S wrote:

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.

Seems like WaitForMultipleObjects is more similar to select() than
poll(), though: it has a fixed limit (MAXIMUM_WAIT_OBJECTS) on the
number of objects you can wait on at once.

But WaitForMultipleObjects can do things that poll can not, like
waiting on semaphore or on event or on thread (for completion, which
POSIX people, in their eternal fondness for idiotic names call
'join').

There are actually some straightforward techniques to handle that.

<https://manpages.debian.org/eventfd(2)>
<https://manpages.debian.org/signalfd(2)>

There are slightly more roundabout ways to do it within vanilla POSIX,
too. There’s an old technique -- I think invented by Daniel Bernstein
-- where worker threads can report their termination back to the main
thread by writing to a pipe. I use that technique here (look! actual C
code for a change!) <https://gitlab.com/ldo/slow_dbus_server>.

As to "the one way", you yourself mentioned substantially different way
in your post here several weeks ago - stackless co-routines. Even if
ends up the same under the hood, it appears quite different from
perspective of application programmer.

It is still built on the exact same underlying poll/select calls --
that’s the whole point. It allows for interoperability, too. Yes, it
does make a lot of things easier -- that, too, is part of the point.

Interesting to see how trying to implement such event loops on Windows
is far from straightforward. Python has to offer a choice of 2
different implementations, neither of which quite covers all the bases
<https://docs.python.org/3/library/asyncio-eventloop.html#event-loop-implementations>.

I don't know where was a catch. As a matter of fact, cygwin people
found solution, so the problem was soluble.

But not, it seems, by Microsoft ...