31 May
2020
31 May
'20
6:46 p.m.
Sorry to top post, but LSX or Miniunix had non blocking I/O as well. It was
in one of the documents that Clem scanned in the last year. It specifically
was an experiment into how to do it.
Warner
On Sun, May 31, 2020, 10:07 AM Clem Cole <clemc(a)ccc.com> wrote:
On Sun, May 31, 2020 at 7:10 AM Paul Ruizendaal <pnr(a)planet.nl> wrote:
This behaviour seems to have continued into
SysVR1, I’m not sure when
EAGAIN came into use as a return value for this use case in the SysV
lineage. Maybe with SysVR3 networking?
Actually, I'm pretty sure that was a product of the POSIX discussions.
BSD already had networking an EWOULDBLOCK. We had argued about
EWOULDBLOCK a great deal, we also were arguing about signal semantics.
I've forgotten many of the details, Heinz may remember more than I do.
EAGAIN was created as a compromise -- IIRC neither system had it yet.
SVR3 networking was where it went into System V, although some of the AT&T
representatives were none too happy about it.
In the Research lineage, the above SysIII approach does not seem to
exist, although the V8 manual page for open() says under BUGS "It should be
possible [...] to optionally call open without the possibility of hanging
waiting for carrier on communication lines.” In the same location for V10
it reads "It should be possible to call open without waiting for carrier on
communication lines.”
The July 1981 design proposals for 4.2BSD note that SysIII non-blocking
files are a useful feature and should be included in the new system. In
Jan/Feb 1982 this appears to be coded up, although not all affected files
are under SCCS tracking at that point in time. Non-blocking behaviour is
changed from the SysIII semantics, in that EWOULDBLOCK is returned instead
of 0 when progress is not possible. The non-blocking behaviour is extended
beyond TTY’s and pipes to sockets, with additional errors (such as
EINPROGRESS). At this time EWOULDBLOCK is not the same error number as
EGAIN.
My memory is that Keith was the BSD (CSRG) person at the POSIX meeting
(he, Jim McGinness of DEC, and I created PAX at one point as a
compromise). I wish I could remember all of the details, but this was all
argued at the POSIX meetings.
As I said before the folks from AT&T just wanted to take the SVID and
rubber stamp it at the specification. Part of it the problem was they
wanted to be free to do what things/make choices that the rest of us might
or might not like (for instance, they did not want the sockets interface).
It would seem that the differences between the BSD and SysV lineages in
this area persisted until around 2000 or so.
Yep - cause around then POSIX started to settle out and both systems began
to follow it.