Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Sun, 26 May 2024 16:51:31 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <eg675jp3q4uvnjtuei6eno0dirn9jb1hp6@4ax.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: i2pn2.org;
	logging-data="2319324"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="h5eMH71iFfocGZucc+SnA0y5I+72/ecoTCcIjMd3Uww";
User-Agent: ForteAgent/8.00.32.1272
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4059
Lines: 56

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.

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


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.


>The difference between Windows APC and RSX/VMS AST is how they are delivered.
>Despite the name, Windows user mode APC's are NOT delivered to the thread
>asynchronously as interrupts but only at specified delivery points,
>which means user mode APC's are essentially a synchronous polled delivery.
>whereas VMS AST's are delivered at any time using interrupts semantics.
>(Windows does have real asynchronous-delivery APC's but inside the kernel
>where they are used to interrupt or wake up a thread for I/O completion
>and various other things.)

>User mode APC's are simpler from a user mode programming point of view than
>VMS's AST's but because APC's have a polled delivery you can't use user mode
>APC's to interrupt and force a thread to do something, as AST's can.