Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Fri, 14 Mar 2025 16:25:48 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <vr2dts$29d9l$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vql9fu$vluh$1@dont-email.me>
 <vqlfrj$10rr4$2@dont-email.me> <vqli6g$114cj$3@dont-email.me>
 <vqm0b9$179ca$1@dont-email.me> <vqnfvp$1gsl4$2@dont-email.me>
 <20250310135828.116@kylheku.com> <vqnkdq$1gsl4$6@dont-email.me>
 <vqnmbn$1i1s0$6@dont-email.me> <vqnmig$1ie8j$2@dont-email.me>
 <vqns51$1jibk$5@dont-email.me> <vqo5hd$1lant$1@dont-email.me>
 <vqo9df$1ls6a$2@dont-email.me> <vqoe8o$1qblf$1@dont-email.me>
 <vqolqv$1rfnf$5@dont-email.me> <vqq8v2$262gq$1@dont-email.me>
 <vqqf3r$273mt$6@dont-email.me> <vqqjra$286h8$2@dont-email.me>
 <vqqlff$28fls$7@dont-email.me> <vqqtjv$2a3dv$1@dont-email.me>
 <vqqu21$2a18r$3@dont-email.me> <vqr25u$2eit2$1@dont-email.me>
 <vqras6$2fsqk$1@dont-email.me> <vqtq8v$33itc$1@dont-email.me>
 <vqvfl6$3rsid$2@dont-email.me> <vqvqmq$49pc$1@dont-email.me>
 <vr01sp$9jrt$2@dont-email.me> <vr212d$1uc77$1@dont-email.me>
 <vr26ih$23hho$1@dont-email.me> <vr299n$25gok$1@dont-email.me>
 <vr2ckr$2872d$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 15 Mar 2025 00:25:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f54594f8eb80134925da391bfb78d663";
	logging-data="2405685"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18t3s/aJdhPT91AVKjSRTC3L+TZuwPoaA4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XsiWNBY8MXOnTmMZTXBZJVsgN9s=
In-Reply-To: <vr2ckr$2872d$2@dont-email.me>
Content-Language: en-US
Bytes: 3710

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!