Deutsch   English   Français   Italiano  
<vr2e4v$29d9l$2@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: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
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: <vr2e4v$29d9l$2@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <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>
 <vr2dts$29d9l$1@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: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: <vr2dts$29d9l$1@dont-email.me>
Bytes: 4310

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