3 Jun
2020
3 Jun
'20
12:23 a.m.
On Tue, Jun 2, 2020 at 1:47 PM Paul Winalski <paul.winalski(a)gmail.com>
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.