On Tue, Jun 2, 2020 at 1:47 PM Paul Winalski wrote: > The operating systems that I cut my teeth on (OS/360, DOS/360, > VAX/VMS) all had basic I/O system calls that were non-blocking. > Blocking I/O calls were all built on top of that framework. I thus > found it curious that Unix took the opposite tack, and non-blocking > I/O was an afterthought. > > So I'm curious as to what the rationale was for Unix to have been > designed with basic I/O being blocking rather than asynchronous. > Especially that non-blocking I/O primitives were the norm for OSes in > those days. 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.