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.
Ryan
On Fri, 18 Mar 2005 09:00:26 -0800, Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
> --On Friday, March 18, 2005 11:27 AM -0500 Ryan Bloom <[EMAIL PROTECTED]>
> 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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
