Date: Tue, 22 Jan 2002 12:00:48 -0800 From: David Greenman <dg@root.com> To: Alfred Perlstein <bright@mu.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_syscalls.c Message-ID: <20020122120048.B50580@nexus.root.com> In-Reply-To: <20020122104431.X13686@elvis.mu.org>; from bright@mu.org on Tue, Jan 22, 2002 at 10:44:31AM -0800 References: <200201221732.g0MHWAR50160@freefall.freebsd.org> <20020122104431.X13686@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>* David Greenman <dg@FreeBSD.org> [020122 09:32] wrote: >> dg 2002/01/22 09:32:10 PST >> >> Modified files: >> sys/kern uipc_syscalls.c >> Log: >> Fixed bug in calculation of amount of file to send when nbytes !=0 and >> headers or trailers are supplied. Reported by Vladislav Shabanov >> <vs@rambler-co.ru>. > >There's a problem here where people actually figured out this buggy >behaviour and worked around it, however now you've broken their >workarounds. This is why in a previous email (private I think) I >suggested you use the flags argument or make a new syscall to >implement the proper behaviour. > >see revision 1.6 of src/lib/libc_r/uthread/uthread_sendfile.c. >-or- >http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc_r/uthread/uthread_sendfile.c?rev=1.6&content-type=text/x-cvsweb-markup > >Apache 2.x depends on the old behaviour as well. I somehow convinced myself that this problem only affected what was returned as sent, not what was actually sent. Gack. Yes, this is going to require some backwords compatibility gook before it is MFC'd. >While you're here, you realize that sendfile's sideways return is >pretty confusing, specifically the case where non-blocking IO is >being done you can get back EAGAIN along with sbytes != 0. Most >other syscalls, (write(2), read(2)) will return a short count and >no error if they would block. I'm not sure if I understand. If you haven't sent all of the headers+file+ trailers and sendfile would block (in non-blocking mode), then it should return the number of bytes sent and EAGAIN to indicate that it isn't finished. Since sendfile allows you to spec "nbytes=0" as a special case to indicate that the whole file should be sent, I don't see how it can be any other way. In other words, how would the application know if it was finished if it hadn't looked up the file size first and kept track of everything itself? Doing all of that would completely defeat the purpose of nbytes = 0. >I don't strongly object to MFC'ing this fix, but I think at least: >1) FreeBSD version needs to be bumped in both 5.x and 4.x. >2) If MFC'd please provide a osendfile function to not break applications. Yeah, I can appreciate the need for that. >3) consider fixing the sideways return as well to just return a partial > count in sbytes and not an error? > (ret == -1 && errno == EAGAIN && sbytes != 0) Considered. :-) -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020122120048.B50580>