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