Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.lang.c Subject: Re: Python recompile Date: Fri, 14 Mar 2025 16:29:34 -0700 Organization: A noiseless patient Spider Lines: 50 Message-ID: References: <20250310135828.116@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 15 Mar 2025 00:29:35 +0100 (CET) Injection-Info: dont-email.me; posting-host="f54594f8eb80134925da391bfb78d663"; logging-data="2405685"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+abcBnNL3c+ZQOuYYUu2XYeM58lRBm0eY=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:L7J5qyGINDP5ibgqD3DRL7MJG8Y= Content-Language: en-US In-Reply-To: On 3/14/2025 4:25 PM, Chris M. Thomasson wrote: > On 3/14/2025 4:03 PM, Lawrence D'Oliveiro wrote: >> On Fri, 14 Mar 2025 15:06:47 -0700, Chris M. Thomasson wrote: >> >>> On 3/14/2025 2:20 PM, Lawrence D'Oliveiro wrote: >>> >>>> Does that require explicitly queuing a read or a write operation? >>> >>> Well, I still don't know how Python is implementing things. >> >> The question is, how do *you* think they should be implemented, in such a >> way that those claimed limitations would not exist? > > I would need to study up on the Python way of implementing these under > the hood. Python using ICOP, vs Python using AIO or something. God knows > what they have done. As to their limitations, I never worked with Python > async io, so I don't know. I know the way I use IOCP over on windows is > fine. > > >>> Keep in mind that successful IOCP means the completion of an io action >>> has occurred, or an error has been raised. It could be a new connection, >>> a buffer was sent, data has been read. That is the C (completion) in >>> IOCP, see? >> >> In other words, you actually have to have queued I/O operations >> outstanding on every connection in order to use IOCP. Dave Cutler >> basically reinvented VMS-style programming, with completion callbacks, in >> a slightly more message-based form. >> > > If you want to receive data, you queue a receive. When it completes its > either successful or its not. Deal with it accordingly. If you want to > connect, queue a connect. When its completed its either successful or > not, ect, for accept, ect... > > >> This kind of thing does not scale to having thousands of connections open >> at once. > > Yawn. Of course it does! 50,000 concurrent connections way back in early > 2000's. What the heck are you even talking about? ;^o Argh! Heck. You are making me remember a special trick in order to get 50,000 concurrent connections on older windows server systems back in the early 2000's. There is a way to tell IOCP to do a so-called "zero byte receive" where it does not use any non-paged memory for the receive buffer because it's zero. Then when IOCP completes it means you are guaranteed a non-blocking receive call, pretty nice! It's meant for the server to use when things start to get tight, so to speak...