Re: OT: Windows (Was: Re: Open Source does not mean easily

In article <vlioum$24bqm$1@dont-email.me>,  <Muttley@DastardlyHQ.org> wrote:

On Mon, 6 Jan 2025 16:39:49 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:

In article <vlgun1$1minf$1@dont-email.me>,  <Muttley@DastardlyHQ.org> wrote:

On Mon, 6 Jan 2025 15:22:51 -0000 (UTC)
Multiplexing is not asychronous, its simply offloading status checking to
the kernel.

>
Of course.  It's a means to allow a program to respond to
asynchronous events.

>
Thats not the same as the program itself being asynch.

Isn't it?  The point is that the program kicks off multiple
asynchronous operations; the issue comes when figuring out what
to do when they complete.  In general, there are only really two
choices here: either poll their completion status, or expect to
be notified by some kind of an event.  In a POSIX-y environment,
`poll`/`select` etc give you the former; signals give you the
latter.

The program using is still very much sequential , at least at
that point.

>
But the events are not.  That's the point.  This allows a
program to initiate a non-blocking IO operation (like, say,
establishing a TCP connection using the sockets API), go do
something else, and check it's status later.

>
Thats not proper asych, its still sequential. Proper asynch is when the
program execution path is directly modified by external events. Otherwise
you could claim simply using the standard file I/O system is asynchronous
programming as there's no guarantee that any data has been written to the disk
before write(), fprintf() etc return.

This is conflating multiple things.  Most IO operations dealing
with the actual hardware _are_ asynchronous (this is what
McIlroy meant in the quote I posted earlier).  The system call
interface gives the program the illusion of those happening
sequentially, but that's not how the devices really work.

It turns out the simple model of early research Unix was
insufficient for handling all sorts of important use cases,
hence why interfaces like `select` and `poll` were added.

Posix AIO is not asynch in the strict sense , its more "ok kernel, go do this
and I'll check how you're doing later". Proper asynch where the program
execution path gets bounced around between various callbacks is something
else entirely.

>
The POSIX AIO interface allows the kernel to generate a signal
to inform the program that an IO operation has completed, e.g.,
by setting up the `aio_sigevent` and `SIGEV_SIGNAL`.  It doesn't
get much more asynchronous than that.

>
Sure, but as I've said before, signals should only set flags to be processed
later.

You said that, but that flies in the face of 50 years of
evidence to the contrary and the letter of the standard.  This
doesn't mean that you should do arbitrary amounts of work in a
signal handler, but there's no reason that, say, one couldn't
push an event onto a queue and signal a condition variable or
something similar.

- Dan C.