Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Lawrence D'Oliveiro 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: References: <20250304092827.708@kylheku.com> <871pv861ht.fsf@nosuchdomain.example.com> <20250308192940.00001351@yahoo.com> <20250309012626.00001276@yahoo.com> <20250309112807.0000489d@yahoo.com> <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. 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!) . > 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 . > 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 ...