Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Sat, 1 Jun 2024 13:28:01 -0700
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <v3g08i$2uv6u$2@dont-email.me>
References: <06ca70b0f9a7f44c59dd827779ad855e@www.novabbs.org>
 <JbO1O.4264$ND9f.2639@fx39.iad> <v28ouo$2dptd$1@dont-email.me>
 <ad22O.8001$1%Qc.4507@fx18.iad> <v2bg2a$318im$1@dont-email.me>
 <mUc2O.11686$tPfe.3221@fx17.iad> <v2ds3r$3itvc$1@dont-email.me>
 <v2dsgr$3itvc$2@dont-email.me> <v2dt0m$3itvc$3@dont-email.me>
 <v2dt9m$3itvc$4@dont-email.me> <v2dtk8$3itvc$6@dont-email.me>
 <HdK2O.2671$pIPf.452@fx43.iad> <v2onfv$200g4$5@dont-email.me>
 <PQ04O.2329$1tf.1802@fx38.iad> <eg675jp3q4uvnjtuei6eno0dirn9jb1hp6@4ax.com>
 <2215O.5358$zHo8.1112@fx47.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 01 Jun 2024 22:28:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8bae63a06eccabd5b54b87dfea012df6";
	logging-data="3112158"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5ghz7thfRg5H7LCXKswwM/pylqRz3Rac="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:m1dnPk76KdzHaTi+4NmSIR52EEw=
Content-Language: en-US
In-Reply-To: <2215O.5358$zHo8.1112@fx47.iad>
Bytes: 5852

On 5/27/2024 7:46 AM, EricP wrote:
> George Neuner wrote:
>> On Fri, 24 May 2024 09:43:19 -0400, EricP
>> <ThatWouldBeTelling@thevillage.com> wrote:
>>
>>> Chris M. Thomasson wrote:
>>>> On 5/20/2024 8:44 AM, EricP wrote:
>>
>>>>> Thanks. I have never used the thread-per-client model in my servers.
>>>>> I have been using async I/O and Asynchronous Procedure Calls (APC)
>>>>> for I/O completion on Windows for 30+ years. IO Completion Ports 
>>>>> (IOCP),
>>>>> which were added to Windows later, have similar functionality
>>>>> (perhaps IOCP might have slightly better scaling with many cores).
>>>> I never tried APC wrt IO and a socket server on windows before! I 
>>>> have created several types wrt the book I finally found on the 
>>>> wayback machine. IOCP was the thing to use.
>>> APC's are I/O completion callback subroutines with 1 to 3 arguments.
>>> I use them to a build callback driven state machines for each network
>>> I/O channel, similar to device drivers. Each network channel requires
>>> only a small amount of user mode memory, and all server network 
>>> connections
>>> can be serviced by a single thread or a small fixed pool of comms 
>>> threads.
>>> This keeps the cost for each new connection to mostly just the kernel's
>>> network memory.
>>>
>>> WinNT originally only had APC's. It inherited the concept from
>>> VMS's Asynchronous System Trap (AST), which inherited the concept
>>> from RSX-11 on PDP-11.
>>
>> I can't speak to "originally" as I never used NT3.x, but NT4.x allowed
>> asynchronous I/O calls to signal events on completion (or failure).  I
>> used events with WaitForMultipleObjects [*] to mix file and socket
>> operations in single-thread servers.
> 
> Since NT 3.1 IO completion was indicated by either an event flag set or 
> APC.
> Internally it uses a kernel mode APC to wake up the thread,
> which then cleans up after the IO and the last thing that APC
> does is either repost itself to the thread as a user mode APC
> or it sets the requested event flag and deletes itself.
> Later they added IO Completion Ports.
> 
> But often layered software packages didn't support this which is
> why I make direct Windows OS calls whenever possible.
> 
>> [*] like select() or poll() in Unix.  For a long time the Windows
>> "WaitFor..." calls could NOT directly monitor sockets (sockets were
>> not files), but they could could monitor user events, and both the
>> file and socket APIs supported using completion events.
> 
> The problem with the event approach is that WaitForXxx only allows up to
> 64 wait objects, and you would need 2 events per network connection,
> one for send and one receive. That WaitFor limit in turn forces the
> thread-per-client model.
> 
> Whereas I want a server to wait for arbitrary numbers of clients IO's,
> hundreds, thousands, tens of thousands..., as many as kernel memory allows.
> 
> That's not to say that completion routines don't have their idiosyncrasies.
> Like everything in Windows land, you have to discover these.
> 
> I originally used named pipes between Windows machines.
> But if I was using sockets I would have used direct calls to WSA
> like WSARecv and WSASend which do support completion routines,
> and not used the standard socket interface libraries.
> 
> https://learn.microsoft.com/en-us/windows/win32/winsock/winsock-functions
> https://learn.microsoft.com/en-us/windows/win32/api/Winsock2/nf-winsock2-wsarecv
> 
> None of my Windows code will ever be ported to another platform so
> compatibility with *nix is irrelevant and the Linux AIO functions
> are completely different anyway.
> 
>> APCs might have been more efficient, but I only ever used them in
>> conjunction with threads - I never tried to write a single-thread
>> server that performed operations on multiple files or sockets using
>> only APC.

It's a bit difficult for me to remember right now, but did you use 
Kernel APC's? Iirc, the pthread-win32 lib used kernel APC's to help 
emulate breaking into a thread at any time. Think of 
PTHREAD_CANCEL_ASYNCHRONOUS. Here is the lib:

https://sourceware.org/pthreads-win32/

Way back, I used this lib all the time. However, I never used pthread 
cancellation. Just never liked it.

[...]