Re: [TUHS] non-blocking IO

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 &lt;clemc(a)ccc.com <mailto:clemc@ccc.com>> wrote: On Sun, May 31, 2020 at 7:10 AM Paul Ruizendaal &lt;pnr(a)planet.nl <mailto:pnr@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.