apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <rbl...@gmail.com>
Subject Re: do we still want sendfile enabled with our default conf files?
Date Fri, 18 Mar 2005 17:10:13 GMT
I didn't dig into the problems that I was seeing on Linux, but I know
that it was IPv4.  I don't know the filesystem, but I can find out.  I
assumed it was the mutli-threaded aspect that was causing the trouble,
but that was really just a guess.


On Fri, 18 Mar 2005 09:00:26 -0800, Justin Erenkrantz
<justin@erenkrantz.com> wrote:
> --On Friday, March 18, 2005 11:27 AM -0500 Ryan Bloom <rbloom@gmail.com> wrote:
> > 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.
> I tend to prefer Jeff's solution of having APR return APR_ENOTIMPL when the
> APR_SENDFILE_AUTODETECT flag is set and we'd fail.  I'm ambivalent if we
> decide to have apr_socket_sendfile() internally call emulate_sendfile because
> apr_socket_sendfile() has always been an optional function (APR_HAS_SENDFILE).
> If we go this route of having it mask the choice, then apr_socket_sendfile()
> should always be present and we can clean up the code in httpd accordingly.
> I also think that we likely already know the cases when sendfile is going to
> succeed on a particular platform.  I haven't heard any claims that sendfile()
> fails on Linux when using only IPv4 and ext{23}.  So, yes, I think we can do
> better than a straight APR_ENOTIMPL - but if people don't want to write the
> checks, then we'll just live with writev() on that platform.  -- justin

Ryan Bloom

View raw message