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

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

On Mon, 6 Jan 2025 14:08:44 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:

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

On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:

In article <vlecm0$1465i$1@dont-email.me>,  <Muttley@dastardlyhq.com> wrote:

On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:

On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>

For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?

>
Almost certainly not. Because process creation is an expensive operation
on Windows.
>
Windows NT was masterminded by Dave Cutler, who was previously responsible

>

for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of

>

a bunch of them at DEC. They would instinctively turn away from Unix ways
of doing things, like forking multiple processes. So the systems they
created did not encourage such techniques.

>
Presumably VMS relied heavily on multithreading then like Windows or was a
process expected to everything itself sequentially?

>
Many system services on VMS are asynchronous, and the system
architecture provides a mechanisms to signal completion; ASTs,
mailboxes, etc.  Thus, many programs (not all) on VMS are
written in a callback/closure style.

>
I imagine that could become complicated very quickly and presumably relies
on the OS providing the signalling mechanisms for everything you might
want to do - eg waiting for a socket connection (or whatever the decnet
equivalent was).

>
It's a fairly common way to structure software even today.  As I

>
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 asynchronous tasks, though not using the callback
model per se (one polls a set of e.g. file descriptors and
dispatches explicitly based on their states as reported by the
polling interface).  Most recently, things like io_uring on
Linux are designed specifically to support asynch IO in user
programs.

Granted, the Unix system interface is not particularly
asynchronous-friendly, but that is by design.  As Doug McIlroy
put it,

|The infrastructure had to be asynchronous. The whole point was
|to surmount that difficult model and keep everyday programming
|simple.  User visibility of asynchrony was held to a minimum:
|fork(), signal(), wait().  Signal() was there first and
|foremost to support SIGKILL; it did not purport to provide a
|sound basis for asynchronous IPC.
(https://tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/IAAO2MRTMSX3C54YGTNOTIT4FEQA73IR/)

This was fine for writing `cat` and `cp` etc, which were largely
synchronous anyway.  Less so for server-style programs or
programs that had to multiplex data from many sources generally.

This early decision to favor the comprehensibility of one class
of program in the system call interface has had reverberations
through time, leading to much complexity.  This is one reason
that, for example, the Go runtime has to jump through so many
hoops to mux goroutines onto the underlying OS-provided thread
abstraction; or that the implementation of async executors for
Rust is hard (cf Tokio).  In that same message referenced above,
Doug continues:

|The complexity of sigaction() is evidence that asynchrony
|remains untamed 40 years on.

This is unfair.  It's evidence that grafting it onto an existing
highly synchronous system interface that was simply not designed
to accommodate it in the first place is very hard, even 50 years
after the fact.

- Dan C.