Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Wed, 12 Mar 2025 14:22:53 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <vqstve$2qf7a$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq6f8p$1pmnk$1@dont-email.me>
 <vq6gqc$1qcp8$1@dont-email.me> <vq6ips$1pmnk$2@dont-email.me>
 <vq6j5h$1qosf$1@dont-email.me> <20250304092827.708@kylheku.com>
 <vq7g1p$1vmg5$1@dont-email.me> <vq94dt$2boso$1@dont-email.me>
 <vqcsk7$23bfo$1@paganini.bofh.team> <vqefn1$3flpt$1@dont-email.me>
 <vqeu5c$3imil$1@dont-email.me> <vqeun4$3iqbq$1@dont-email.me>
 <vqfcbe$3lkkc$1@dont-email.me> <871pv861ht.fsf@nosuchdomain.example.com>
 <20250308192940.00001351@yahoo.com> <vqi1ge$8jg8$1@dont-email.me>
 <vqibt3$ahu0$3@dont-email.me> <vqiibq$bq1o$7@dont-email.me>
 <20250309012626.00001276@yahoo.com> <vqiugc$dv5o$2@dont-email.me>
 <20250309112807.0000489d@yahoo.com> <vql2bf$uei7$2@dont-email.me>
 <20250310152000.00004955@yahoo.com> <vqnm1h$1i1s0$4@dont-email.me>
 <vqnm88$1ievf$1@dont-email.me> <vqns1v$1jibk$4@dont-email.me>
 <vqo1n4$1kkf3$3@dont-email.me> <vqo9cl$1ls6a$1@dont-email.me>
 <vqodvi$1qbli$1@dont-email.me> <vqoe3v$1qbli$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 12 Mar 2025 22:22:55 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2ef4e7aaa99a36084a927a6ac123e306";
	logging-data="2964714"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5Io0uJS9PfaI8P8ITOJD+Zi4kOC0+9jQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:nXxMS65UAQ9Pza3Xp/RirU+jWFg=
Content-Language: en-US
In-Reply-To: <vqoe3v$1qbli$2@dont-email.me>
Bytes: 3977

On 3/10/2025 9:27 PM, Chris M. Thomasson wrote:
> On 3/10/2025 9:25 PM, Chris M. Thomasson wrote:
>> On 3/10/2025 8:07 PM, Lawrence D'Oliveiro wrote:
>>> On Mon, 10 Mar 2025 17:56:03 -0700, Chris M. Thomasson wrote:
>>>
>>>> On 3/10/2025 4:19 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>>> On Mon, 10 Mar 2025 14:40:23 -0700, Chris M. Thomasson wrote:
>>>>>
>>>>>> For some damn reason I am remembering that the array that
>>>>>> WaitForMultipleObjects waits on should be "shifted" or even 
>>>>>> randomized
>>>>>> per call in a server loop that is using EVENTS. IIRC, this was way
>>>>>> back in late 90's and early 2000's.
>>>>>
>>>>> I would hope that the order of entries is not important, as that would
>>>>> defeat the point of non-determinism.
>>>>
>>>> I remember reading a paper on the 50,000 concurrent connections issue
>>>> wrt IOCP vs events. Well, it made sure to tell the user to at least
>>>> shift the array that WFMO's waits on, per call in the server loop.
>>>
>>> But why? Surely events relevant to entries in the list should be 
>>> serviced
>>> in the order they arrive, not in the order in which the entries 
>>> happen to
>>> occur in the list. There is no other reasonable way to do it.
>>
>> Well, it just the way WFMO is implemented. Notice that post from Kaz 
>> wrt the index... I remember reading about it is more than one place 
>> now, for some damn reason. NT insider comes to mind.
> 
> There was an interesting issue with IOCP used with sockets. If one 
> issued multiple overlapped operations, they could complete in any order. 
> So, I would have to do a little sort on them to make sure my program 
> logic got them in order.

Even if I issued, say, five WSARecvs on the same exact socket. The 
receives could be picked by IOCP and delivered to my server threads out 
of order. So, I would extend the OVERLAPPED struct, or should I say 
WSAOVERLAPPED...To give me a sequence number.