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 19:35:32 -0700 Organization: A noiseless patient Spider Lines: 15 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 03:35:33 +0100 (CET) Injection-Info: dont-email.me; posting-host="f54594f8eb80134925da391bfb78d663"; logging-data="2680969"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19W5fvfsQXBnTCu9+7ZujkQNbYSQ5C8r00=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:NQWg5anZvzOSjCudiCGmNOYkSoA= Content-Language: en-US In-Reply-To: On 3/14/2025 7:31 PM, Lawrence D'Oliveiro wrote: > On Fri, 14 Mar 2025 16:29:34 -0700, Chris M. Thomasson wrote: > >> 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! > > Not sure why you need such a roundabout trick just to get a nonblocking > version of an I/O call. Well, ideally this would be a last resort, so to speak. When the system is under moderate load, we would use multiple overlapped WSARecv's and WSASend's. However, when things got a bit tight, switch to the zero-byte-receive trick that I learned about many moons ago.