[TUHS] non-blocking IO

[Clem Cole]

On Sun, May 31, 2020 at 7:10 AM Paul Ruizendaal <pnr at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200531/9b67c7a9/attachment.htm>