Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of rbloom@gmail.com designates
 64.233.184.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=ElAm9pogjG/mz73TOY7HXPLvwHk+AStzAPNKADhBlGKmizYNYfu7aEYhnVaea8Juz/TZsWEjVdq8UFIEIT6awwSN5nTqGIhcfF++aVvLDQsGqxHFXu4zVVswUXXXWJVqcZE/JzF0MturFD9nz7XIg3hZtbbmj5V0xP3/HNpV95M=
Message-ID: <1f1d982050318082726d1a8ad@mail.gmail.com>
Date: Fri, 18 Mar 2005 11:27:23 -0500
From: Ryan Bloom <rbloom@gmail.com>
Reply-To: Ryan Bloom <rbloom@gmail.com>
To: Justin Erenkrantz <justin@erenkrantz.com>
Subject: Re: do we still want sendfile enabled with our default conf files?
Cc: Jeff Trawick <trawick@gmail.com>, dev@httpd.apache.org, dev@apr.apache.org
In-Reply-To: <6A59038878FF133648C83BDC@10.0.1.81>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <cc67648e05031704575741b217@mail.gmail.com>
	 <42398A5C.7000400@slive.ca>
	 <20050317141250.GA28555@castlerea.stdlib.net.>
	 <20050317152754.GI5790@scotch.ics.uci.edu>
	 <cc67648e050317160175a8a153@mail.gmail.com>
	 <20050318013331.GO5790@scotch.ics.uci.edu>
	 <cc67648e0503180259929bc4@mail.gmail.com>
	 <CE3CD595B8676A3F6F4E5BD5@10.0.1.81>
	 <1f1d98205031808126698802b@mail.gmail.com>
	 <6A59038878FF133648C83BDC@10.0.1.81>

That's fine.  Pay attention to what I suggested.  Default to
non-native sendfile, until we have know that it works.  If you have an
OS that you know for a fact does sendfile correctly, then that would
be a case where we know that it works.

Instead of

#ifndef LINUX|WIN32|AIX|HPUX
    sendfile(....)
#else
    fake_sendfile(....)
#endif

do:

#ifdef SomeOSThatWorks
    sendfile(.....)
#else
    fake_sendfile(....)
#endif

Since the beginning of APR, we thought that we knew how to get
sendfile working on most of our supported OS'.  That's why we included
sendfile support.  It turns out though, that for many of those
platforms, sendfile just doesn't work in some situations.  When we
have a platform without the bugs, then yes we should use sendfile, but
for all other cases I care infinately more about correctness than
speed.

Ryan


On Fri, 18 Mar 2005 08:23:18 -0800, Justin Erenkrantz
<justin@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom <rbloom@gmail.com> wrote:
> 
> > funny, I took the list of exceptions to be so large and hard to
> > maintain that it made more sense to go with Jeff's original idea of
> > just disabling sendfile by default unless a user specifically decided
> > to enable it.  I just had to debug a problem for a friend with
> > sendfile on Linux.  I don't know what caused the problem, but
> > disabling sendfile solved it immediately.  Seems to me that until our
> > sendfile support is better, we should err on the side of always
> > sending the data correctly instead of absolutely as fast as possible.
> 
> I absolutely refuse to punish users who are using good OSes because some OSes
> are brain-dead.  This is exactly the role that APR is meant to fill: if we
> know of conditions where it is unsafe to use sendfile, we won't use it unless
> explicitly told so by the user.
> 
> The minimal check can be:
> 
> if (flags & APR_SENDFILE_CHECK) {
> #ifdef LINUX || WIN32 || AIX || HPUX
>     return APR_ENOTIMPL;
> #endif
> }
> 
> As people determine what conditions sendfile is safe (or causes problems),
> then we can add those.
> 
> Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I
> don't care.  However, blocking sendfile on non-buggy OSes is not a solution
> that I am willing to sign off on.  -- justin
> 


-- 
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com