Paul Winalski <paul.winalski(a)gmail.com> wrote: I don't doubt that it was "simplify, simplify, simplify". Async I/O is much messier than Unix's read/write model. The Unix model was simpler to design, simpler to code, simpler to get right, and undoubtedly took much less OS code than an async model would have; on the PDP-11 that would have mattered. Also, the early Unixs were on smaller -11s, not the /45 or /70 with split I&D space and the ability to address lost more RAM. My guess, anyway. :-) Arnold

On Tue, Jun 2, 2020 at 2:54 PM Paul Winalski <paul.winalski(a)gmail.com> wrote: Hrrmpt... it was single task. Being asynchronous in the I/O and allowed process asynchrony takes a lot more housekeeping. Paul you know I agree with you, it was always an issue with UNIX IMO. The problem is how to do it differently. At Masscomp RRU, our solution was not to try to 'fix it' as much as add a new scheme beside the synchronous one. We added a general AST's mechanism that anyone could use (very much like RSX and VMS in semantics), but left signals alone. We added new async calls, which were just implemented via ioctl's (the universal hack) for the specific HW that supported it. In retrospect, that was an error, it should have been aread(2)/awrite(2) and then added the completion routine/call back as the 4th & 5th parameters. Since Stellix was not Real-Time, we left them out. [ tjt and I have argued about that for years ]. So back to Doug/Dan's answer -- I think for a small system, like the original PDP-7 and the PDP-11/20 putting the effort to make it multiprocess and leaving the I/O synchronous definitely made it easier. Particularly, since what was created with the signal semantics. To me, UNIX got way more right than wrong. I suspect if signals had been more like AST's, the idea of being async might have gone farther. But to use Dennis's like about C being quirky, signals are very quirky. wnj tried to 'fix' them and frankly it just made matters worse. And IMO, signaction(3) as Doug says, is a nightmare. I've generally been a fan of introducing a new idea separately as a 'stronger strain' and then seeing if people likely it. FWIW: A couple of us did try to get AST's into the POSIX.4 (they were there in a draft), but ultimately *.4 was rejected as 'not UNIX.'

Lawrence Stewart writes: So select was a great thing until interactive graphics came along. Just got too messy. I recall writing assembly language code to support threads in the mid to late 1980s, and I remember reading some papers from Sun about the same. Everybody was doing it. Anybody have enough of the history to paint a picture of how we got from there to standardized threads? Jon

To be more forthcoming, there was a long period when the received wisdom was that threads were unmanageable. But that was a category error: The programming model in POSIX and others was what made it hard. The fundamental concepts are a tiny step harder than trivial, and it was not hard to build a programming model that matched them. The first mistake people made was to split "thread" from "process". What those words mean today is not what they meant a generation ago. For me, it's like the mess sockets made of networking. Our programming models could be so much simpler than what we are required to deal with. -rob

See the description of rfork at http://man.cat-v.org/plan_9/2/fork. -rob On Wed, Jun 3, 2020 at 9:21 AM Larry McVoy <lm(a)mcvoy.com> wrote:

On 6/2/20, Jon Steinhart <jon(a)fourwinds.com> wrote: TOPS-10 had a nifty program called ptycon that would allow one to control multiple login sessions, each on its own pseudo-terminal device, from a single physical terminal. In 1985 our software tools group implemented a pseudo-terminal device driver for VMS, and I wrote a program called ptycon-32. It was multithreaded, with one thread of control for each pseudo-terminal. The problem is that VMS at the time didn't have a threads package. I had to roll my own threads by using the asynchronous system traps (ASTs) delivered by completion of I/O to the pseudo-terminals. Talk about messy.... -Paul W.

Lawrence Stewart wrote: Has this, or Rand's code, been preserved? I'm only aware of one Arpanet NCP implementation for Unix that is online, the one from University of Illinois.

On Tue, Jun 2, 2020 at 1:47 PM Paul Winalski <paul.winalski(a)gmail.com> wrote: Doug addressed this, albeit in an oblique manner, on this list back in 2015: https://minnie.tuhs.org/pipermail/tuhs/2015-September/007509.html Quoting him: """ Unix was what the authors wanted for a productive computing environment, not a bag of everything they thought somebody somewhere might want. One objective, perhaps subliminal originally, was to make program behavior easy to reason about. Thus pipes were accepted into research Unix, but more general (and unruly) IPC mechanisms such as messages and events never were. 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. The complexity of sigaction() is evidence that asynchrony remains untamed 40 years on. """ My response at the time was to question whether asynchrony itself remains untamed, as Doug put it, or if rather it has proved difficult to retrofit asynchrony onto a system designed around fundamentally synchronous primitives? - Dan C.

On Tue, Jun 2, 2020 at 2:58 PM Paul Winalski <paul.winalski(a)gmail.com> wrote: Which was exactly the point I tried to make in the POSIX.4 discussions, but it does take more work in the basic housekeeping and you need a way to handle events and completions that are priority based, queued, and a few other details. As Doug said, they stayed away from some features (like messaging). async I/O was one of them. But as I said, Ken, Dennis and the rest of the crew did an amazing job with very little.