Deutsch   English   Français   Italiano  
<vqnkdq$1gsl4$6@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Mon, 10 Mar 2025 21:36:49 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <vqnm1h$1i1s0$4@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq3oag$18iv6$1@dont-email.me>
	<vq4hf2$1brf7$1@dont-email.me> <vq4l3d$1ck9e$1@dont-email.me>
	<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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 10 Mar 2025 22:36:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="eb6ab2683b3e8e4c3fa2e25a8db8b9cc";
	logging-data="1640320"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX187p54fnxk18gkxG/UOt6zK"
User-Agent: Pan/0.162 (Pokrosvk)
Cancel-Lock: sha1:lbKPbIoNEThzJDIDanqK4DIqRq8=
Bytes: 3919

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 ...