Date: Tue, 22 Jan 2002 12:41:29 -0800 From: Alfred Perlstein <bright@mu.org> To: David Greenman <dg@root.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_syscalls.c Message-ID: <20020122124129.E13686@elvis.mu.org> In-Reply-To: <20020122120048.B50580@nexus.root.com>; from dg@root.com on Tue, Jan 22, 2002 at 12:00:48PM -0800 References: <200201221732.g0MHWAR50160@freefall.freebsd.org> <20020122104431.X13686@elvis.mu.org> <20020122120048.B50580@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* David Greenman <dg@root.com> [020122 12:13] wrote: > > > >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. AH! I didn't consider this... but... did it block while sending the entire file... or when sending the trailers? :) It seems like returning EAGAIN is correct, but the application would need to stat(2) the file to find out at that point if utilizing trailers? I guess we should work some of this discussion into the manpage as it would likely help people using the interface. > >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. :-) Cool, please keep me in the loop. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ 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?20020122124129.E13686>