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

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

On Mon, 6 Jan 2025 15:22:51 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:

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

In Windows yes, which frankly is probably not a coincidence. Not so much
in unix unless you're writing a GUI program.

>
Very much in Unix, actually.  The kernel is highly asynchronous
(it must be, to match the hardware), and has been since the
early 1970s.  Many user programs similarly.
>
Historically, many systems have provided direct support for
asynchronous programming on Unix.  Going back to the early
commerical Unix days, masscomp's real time Unix had ASTs, not
signals, to support asynch IO directly from userspace.  More
recently, POSIX.1b and POSIX AIO are widely supported.  Polling
interfaces like kqueue and epoll, etc, exist largely to support

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

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.

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.

- Dan C.