accept(2): may return EAGAIN

[Jilles Tjoelker]

On Wed, Oct 08, 2014 at 06:11:29PM -0700, Xin Li wrote:
> It seems like accept(2) may and does return EAGAIN.  Do the following
> change look appropriate to you?

> Index: lib/libc/sys/accept.2
> ===================================================================
> --- lib/libc/sys/accept.2	(revision 272709)
> +++ lib/libc/sys/accept.2	(working copy)
> @@ -28,7 +28,7 @@
>  .\"     @(#)accept.2	8.2 (Berkeley) 12/11/93
>  .\" $FreeBSD$
>  .\"
> -.Dd October 1, 2013
> +.Dd October 9, 2014
>  .Dt ACCEPT 2
>  .Os
>  .Sh NAME
> @@ -201,7 +201,7 @@ The
>  .Fa addr
>  argument is not in a writable part of the
>  user address space.
> -.It Bq Er EWOULDBLOCK
> +.It Bo Er EWOULDBLOCK Bc or Bq Er EAGAIN
>  The socket is marked non-blocking and no connections
>  are present to be accepted.
>  .It Bq Er ECONNABORTED

This is correct, but it is inconsistent to write "[EWOULDBLOCK] or
[EAGAIN]" only in one particular man page.

The situation in FreeBSD is that EWOULDBLOCK == EAGAIN. This is
permitted but not required by POSIX. The two errors may have different
numeric values and in the case of socket operations, EWOULDBLOCK may be
returned instead of EAGAIN. (For example, accept(2) may return
[EWOULDBLOCK] instead of [EAGAIN], and read(2) may return [EWOULDBLOCK]
instead of [EAGAIN] if the operation is on a socket.)

Unfortunately, intro(2) does not mention EWOULDBLOCK at all.

BSD flock(2) and the related open(2) flags also use EWOULDBLOCK; these
can probably stay that way (applications need not check for [EAGAIN]).

-- 
Jilles Tjoelker