> trawick 01/05/03 15:38:02
>
> Modified: . CHANGES
> test sendfile.c
> network_io/unix sendrecv.c
> Index: sendrecv.c
> ===================================================================
> RCS file: /home/cvs/apr/network_io/unix/sendrecv.c,v
> retrieving revision 1.64
> retrieving revision 1.65
> diff -u -r1.64 -r1.65
> --- sendrecv.c 2001/03/31 13:25:45 1.64
> +++ sendrecv.c 2001/05/03 22:38:00 1.65
...
> @@ -444,6 +443,13 @@
> &headerstruct, /* Headers/footers */
> &nbytes, /* number of bytes written */
> flags); /* undefined, set to 0 */
> + /* FreeBSD's sendfile can return -1/EAGAIN even if it
> + * sent bytes. Sanitize the result so we get normal EAGAIN
> + * semantics w.r.t. bytes sent.
> + */
> + if (rv == -1 && errno == EAGAIN && nbytes) {
> + rv = 0;
> + }
> }
> else {
> /* just trailer bytes... use writev()
> @@ -462,7 +468,7 @@
> } while (rv == -1 && errno == EINTR);
>
> (*len) = nbytes;
> - if (rv == -1 && (errno != EAGAIN || (errno == EAGAIN && sock->timeout
> < 0))) {
> + if (rv == -1) {
> return errno;
> }
> return APR_SUCCESS;
We have one coredump for an assertion (ohmygod) failure on
apache.org where apr_sendfile() returned APR_SUCCESS/zero-bytes-read
for a socket with a timeout. After reading the code many times I just
don't see how, unless the kernel had a slip-up.
I noticed this weird use of sendfile() in FreeBSD's ftpd.c:
while (err != -1 && cnt < filesize) {
err = sendfile(filefd, netfd, offset, len,
(struct sf_hdtr *) NULL, &cnt, 0);
byte_count += cnt;
offset += cnt;
len -= cnt;
if (err == -1) {
if (!cnt)
goto oldway;
goto data_err;
}
}
I don't understand why there is a loop... (I have no idea if there is
a connection between the unclear need for this loop and BSD's
sendfile() returning 0/0...)
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
