[TUHS] non-blocking IO
clemc at ccc.com
Mon Jun 1 02:05:47 AEST 2020
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
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
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...
More information about the TUHS