> From: Chris Hanson
> you should virtually never use read(2), only ever something like this:
> ...
> And do this for every classic system call, since virtually no client
> code should ever have to care about EINTR.
"Virtually". Maybe there are places that want to know if their read call was
interrupted; if you don't make this version available to them, how can they
tell? Leaving the user as much choice as possible is the only way to go, IMO;
why force them to do it the way _you_ think is best?
And it makes the OS simpler; any time you can move functionality out of the
OS, to the user, that's a Good Thing, IMO. There's nothing stopping people
from using the EINTR-hiding wrapper. (Does the Standard I/O library do this,
does anyone know?)
Noel
PS: Only system calls that can block can return EINTR; there are quite a few
that don't, not sure what the counts are in modern Unix.
On Sun, 4 Nov 2018, Chris Hanson wrote:
> Every piece of code that wants to call, say, read(2) needs to handle
> not only real errors but also needs to special-case EINTR and retry
> the read. Thus you should virtually never use read(2), only ever
> something like this:
> ...
> And do this for every classic system call, since virtually no client
> code should ever have to care about EINTR. It was early an
> implementation expediency that became API and that everyone now has
> to just deal with because you can’t expect the system call interface
> you use to do this for you.
>
>This is the sort of wart that should’ve been fixed by System V and/or BSD 4 at latest.
But it *was* fixed in BSD, and it's in POSIX as the SA_RESTART flag to
sigaction (which gives you BSD signal semantics).
POSIX supports both the original V7 and BSD signal semantics, because
by then there were programs which expected system calls to be
interrupted by signals (and to be fair, there are times when that's
the more convenient way of handling an interrupt, as opposed to using
setjump/longjump to break out of a restartable system call).
- Ted
P.S. The original implementation of ERESTARTSYS / ERESTARTNOHAND /
ERESTARTNOINTR errno handling in Linux's system call return path was
my fault. :-)
The last couple of days I worked on re-setting the V3-V6 manuals.
I reconstructed V5 from the scan as best I could, unfortunately some
pages were missing.
You can find everything I used to do this here,
please read the BUGS section:
https://github.com/aap/unixman
The results can be found here, as HTML and PDF:
http://squoze.net/UNIX/v3man/http://squoze.net/UNIX/v4man/http://squoze.net/UNIX/v5man/http://squoze.net/UNIX/v6man/
Reconstructing V1 and V2 n?roff source and converting the tty 37 output
to ps is something I want to do too, but for now this was exhausting
enough.
Now for the questions that I arose while I was doing this:
Are there scans of the V4 and V6 manual to check my pdfs against?
Where does the V5 manual come from? As explained in the README,
some pages are missing and some pages seem to be earlier than V4.
Is there another V5 manual that one could check against?
Why is lc (the LIL compiler) not in the TOC but has a page?
And most importantly: is the old troff really lost?
I would love to set the manual on the original systems
at some point (and write a CAT -> ps converter, which should be fun).
Doing all this work made me wish we still had earlier versions
of UNIX and its tools around.
Have fun with this!
aap
> From: Clem Cole
> (probably because Larry Allen implemented both UNIX Chaos and Aegis IIRC).
Maybe there are two Larry Allen's - the one who did networking stuff at
MIT-LCS was Larry W. Allen, and I'm pretty sure he didn't do Unix CHAOS code
(he was part of our group at LCS, and we only did TCP/IP stuff; someone over
in EE had a Unix with CHAOS code at the time, so it pre-dated his time with
us).
Noel
Hello,
Which revisions of the "C Reference Manuals" are known to be out there?
I found this:
https://www.bell-labs.com/usr/dmr/www/cman.pdf
Which seems to match the one from V6:
https://github.com/dspinellis/unix-history-repo/tree/Research-V6-Snapshot-D…
"C is also available on the HIS 6070 computer at Murray Hill and and on
the IBM System/370 at Holmdel [3]."
But then there's this:
https://www.princeton.edu/ssp/joseph-henry-project/unix-and-c/bell_labs_136…
"C is also available on the HIS 6070 computer ar Hurray Hill, using a
compiler written bu A. Snyder and currently maintained by S. C. Johnson.
A compiler for the IBM System/360/370 series is under construction."
Due to the description of the IBM compiler, it seems to predate the V6
revision.
Both above revisions use the =+ etc operators.
Finally, this version edited by Snyder:
https://github.com/PDP-10/its/blob/master/doc/c/c.refman
"In addition to the UNIX C compiler, there exist C compilers for the HIS
6000 and the IBM System/370 [2]."
This version documents both += and =+ operators.
Of interest to the old farts here...
At 22:30 (but which timezone?) on this day in 1969 the first packet got as
far as "lo" (for "login") then crashed on the "g".
More details over on http://en.wikipedia.org/wiki/Leonard_Kleinrock#ARPANET
(with thanks to Bill Cheswick for the link).
-- Dave
> From: Steve Johnson
> references that were checked using the pointer type of the structure
> pointer. My code was a nightmare, and some of the old Unix code was at
> least a bad dream.
I had a 'fun' experience with this when I went to do the pipe splice() system
call (after the discussion here). I elected to do it in V6, which I i) had
running, and ii) know like the back of my hand.
Alas! V6 uses 'int *' everywhere for pointers to structures. It also, in the
pipe code, uses constructs like '(p+1)' to provide wait channels. When I wrote
the new code, I naturally declared my pointers as 'struct inode *ip', or
whatever. However, when I went to do 'sleep(ip+1)', the wrong thing happened!
And since V6 C didn't have coercions, I couldn't win that way. IIRC, I finally
resorted to declaring an 'int *xip', and doing an 'xip = ip' before finally
doing my 'sleep(xip+1)'. Gack!
Noel
> From: Dave Horsfall
> We lost ... on this day
An email from someone on a related topic has reminded me of someone else you
should make sure is only your list (not sure if you already have him):
J. C. R. Licklider; we lost him on June 26, 1990.
He didn't write much code himself, but the work of people he funded (e.g.
Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his
vision has led to today's computerized, information-rich world. For people who
only know today's networked world, the change from what came before, and thus
his impact on the world (since his ideas and the work of people he sponsored
led, directly and indirectly, to much of it), is probably hard to truly
fathom.
He is, in my estimation, one of the most important and influential computer
scientists of all. I wonder how many computer science people had more of an
impact; the list is surely pretty short. Babbage; Turing; who else?
Noel