The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <pnr@planet.nl>
To: "tuhs@minnie.tuhs.org list" <tuhs@minnie.tuhs.org>
Subject: [TUHS] V6 networking & alarm syscall
Date: Sat, 12 Jan 2019 00:27:59 +0100	[thread overview]
Message-ID: <37D0F710-9705-497B-BC4B-51B6E1D5FA1C@planet.nl> (raw)

Clem, Ron,

Thanks for the explanations! Some comments below.

>> 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.

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.

> "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'?



             reply	other threads:[~2019-01-11 23:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11 23:27 Paul Ruizendaal [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-01-13 10:52 Paul Ruizendaal
2019-01-13 15:39 ` Warner Losh
     [not found] <mailman.1.1547258402.6716.tuhs@minnie.tuhs.org>
2019-01-12 11:13 ` Paul Ruizendaal
2019-01-12  4:14 Noel Chiappa
2019-01-12  1:24 Noel Chiappa
2019-01-12  1:58 ` Dave Horsfall
2019-01-12  2:33   ` Warner Losh
2019-01-10 23:12 Paul Ruizendaal
2019-01-11  0:17 ` Clem cole
2019-01-11 15:33 ` ron
2019-01-11 18:45   ` Clem Cole
2019-01-11 19:06     ` David
2019-01-11 22:08     ` reed
2019-01-11 22:18       ` Larry McVoy
2019-01-12 12:04         ` reed
2019-01-12 17:20           ` Clem Cole
2019-01-12 18:16             ` Eric Allman
2019-01-13  1:16               ` Madeline Autumn-Rose
2019-01-11 22:47       ` Clem Cole
2019-01-11 22:55         ` Eric Allman
2019-01-11 23:32         ` Warner Losh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37D0F710-9705-497B-BC4B-51B6E1D5FA1C@planet.nl \
    --to=pnr@planet.nl \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).