Re: Making Lemonade (Floating-point format changes)

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