Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Mar 2003 18:23:18 +1100
From:      Peter Jeremy <peterjeremy@optushome.com.au>
To:        Sean Chittenden <sean@chittenden.org>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Should sendfile() to return EAGAIN?  [patch]
Message-ID:  <20030310072318.GA3343@cirb503493.alcatel.com.au>
In-Reply-To: <20030309214638.GN79234@perrin.int.nxad.com>
References:  <20030309135037.GK79234@perrin.int.nxad.com> <Pine.BSF.4.21.0303092026380.85235-100000@is> <20030309214638.GN79234@perrin.int.nxad.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 09, 2003 at 01:46:38PM -0800, Sean Chittenden wrote:
>Eh, well, I vacillate on this topic, but there is something to be said
>for source compatibility.  Using EAGAIN requires no changes to
>existing code.  Returning ENOBUFS does require a change to existing
>code.

I support source compatibility as a guideline but not as a hard-and-fast
rule.  This wouldn't be the first time that source compatability has
been broken and won't be the last time.  In any case, that last "does"
should be "may" - some applications may no care.

Looking at FreeBSD, the only standard application that uses sendfile(2)
is ftpd(8) - and it doesn't care what the actual errno is.  The libc_r
wrapper would need to be modified though and there may be ports that
use sendfile(2).

>  By the same token, it seems more correct to me
>to signify to the app that the OS is maxed (ENOBUFS) as opposed to the
>client being maxed (EAGAIN).  ::shrug::

The descriptions of the errors (from intro(2)) are:
     35 EAGAIN Resource temporarily unavailable.  This is a temporary condi-
             tion and later calls to the same routine may complete normally.
     55 ENOBUFS No buffer space available.  An operation on a socket or pipe
             was not performed because the system lacked sufficient buffer
             space or because a queue was full.

Whilst both errors cover the situation, "ENOBUFS" provides more
information to the caller and I would therefore consider it as the
preferred error.

Peter

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030310072318.GA3343>