[mod.std.unix] Non-blocking I/O and EWOULDBLOCK vs. EAGAIN

jsq@ut-sally.UUCP (John Quarterman) (07/21/85)

as essentially adopted 4.2BSD-style
non-blocking I/O, rather than System V-style non-blocking I/O.  The System V
Interface Definition says that System V will be changed to match the
/usr/group standard.

However,

	1) as the S5ID states, this may break existing code as it isn't
	   compatible with existing System V implementations.

and

	2) it's not compatible with 4.2BSD, either, because they return
	   EAGAIN if a non-blocking operation would have blocked had the
	   descriptor been in non-blocking mode, rather than EWOULDBLOCK.

Is there a good reason for constructing a new specification, incompatible
with *all* existing systems, rather than adopting the existing 4.2BSD
facility which provides the same functionality and merely uses a different
error code?  "The committee didn't want to add a new error code" is an
extremely bad reason, as they have already added new error codes for the
benefit of file locking.  UNIX error codes are far too overloaded already;
the problem should not be compounded.

	Guy Harris

jsq@ut-sally.UUCP (John Quarterman) (07/23/85)

----------------------------------------------------------------------

Date: Sat, 20 Jul 85 16:41:57 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!std-unix
Subject: Non-blocking I/O and EWOULDBLOCK vs. EAGAIN

The /usr/group standards committee has essentially adopted 4.2BSD-style
non-blocking I/O, rather than System V-style non-blocking I/O.  The System V
Interface Definition says that System V will be changed to match the
/usr/group standard.

However,

	1) as the S5ID states, this may break existing code as it isn't
	   compatible with existing System V implementations.

and

	2) it's not compatible with 4.2BSD, either, because they return
	   EAGAIN if a non-blocking operation would have blocked had the
	   descriptor been in non-blocking mode, rather than EWOULDBLOCK.

Is there a good reason for constructing a new specification, incompatible
with *all* existing systems, rather than adopting the existing 4.2BSD
facility which provides the same functionality and merely uses a different
error code?  "The committee didn't want to add a new error code" is an
extremely bad reason, as they have already added new error codes for the
benefit of file locking.  UNIX error codes are far too overloaded already;
the problem should not be compounded.

	Guy Harris

------------------------------

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:	ut-sally!std-unix	or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request	or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)