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)