12 Jan
2019
12 Jan
'19
5:27 a.m.
Clem, Ron,
Thanks for the explanations! Some comments below.
I was too brief. I was referring just to the pre-V7 versions, and I had the implicit
assumption that alarm() originated at the labs. My understanding was that the labels 5th,
6th and 7th edition had little meaning inside the labs, as there just was a continuously
developing code base. Maybe this is a mis-understanding.
1. First of
all: I understand that early Unix version numbers and dates
mostly refer to the manual editions, and that core users had more
frequent snapshots of a constantly evolving code base.
Eh? They primarily refer to the distributions (Research V6, V7, PWB, the
various BSD tapes).
I'm not sure what "core users" are referring to. Most of us had many
versions as we hacked and merged the stock releasesx. "alarm was introduced as part of Unix/TS"
"PWB [..] had both sleep() and alarm() as system calls"
Thanks for those pointers! I'm not sure I fully grasp the lineage of Unix/TS and PWB,
but the TUHS wiki has a page about it:
https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1
From that, and from the TUHS Unix Tree web page I get that PWB1.0 from mid 1977 was
probably the root source of alarm() for people outside AT&T. As PWB apparently got
started much before that, it is possible that alarm() goes back much further as well.
A bigger networking issue was select() (or the like).
It used to be an
interesting kludge of running two processes inorder to do simoultaneous
read/write before that.
Yes: the NCP Unix team (Grossman/Holmgren/Bunch) also mentioned that as the big
issue/annoyance that they ran into in 1975.
As discussed in this list before, 3 years elapsed before Jack Haverty came up with await()
for V6. I was told that there was a lot of discussion in the 4.1x/4.2 BSD steering group
in 1981/2 whether this functionality should be stateful (like await) or stateless (like
select). Looking at the implementations for both, I can see why stateless carried the
day.
Right and select(2) was created by Sam and wnj during
the 4.2 development. I've forgotten which sub-version (it was in 4.1c, but it might
have been in b or a before that). There was a lot of arguing at the time about it's
need; the multiple process solution was considered more 'Unix-like.'
That is an interesting point, and it got me wondering about another related feature that
could have been in Unix in the 1975-1980 time frame, being both useful and practical even
on a 11/40 class machine, but for some reason wasn't:
It would not seem terribly complex to add non-blocking i/o capability to V6. It could have
been implemented as a TTY flag and it is not a big conceptual leap from EINTR to EAGAIN.
Adding a 'capacity' field to the sgtty interface would not have been a big leap
either. This would have allowed user processes to scan a number of tty lines e.g. once a
second in a loop and do processing as needed. In NCP Unix this would not have been hard to
extend to network pipes.
The NCP Unix / Arpanet crowd certainly had a need for it, it would have been very useful
for Spider/Datakit connections and probably for uucp as well. And from there it is not a
million miles to replace the timed user loop with something like select(). Yet
non-blocking I/O and select() only appear in 1982.
Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does it'?