httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: cvs commit: apache-2.0/src/main iol_socket.c
Date Thu, 06 Jul 2000 20:51:27 GMT
On Thu, 6 Jul 2000, William A. Rowe, Jr. wrote:

> But this doesn't answer the fundemental issue that some sockets
> providers will or won't support sendfile on a run-time-tested
> basis... Win32 for certain, and perhaps others.

This all goes back to how does APR work.  Is it run-time or compile-time
based.  Everytime this question has come up, we have had the same
answer.  APR makes decisions about what to support at compile time, unless
it can't, at which point it makes them at run-time.  

Since all Windows platforms use the same projects, they all define
APR_HAS_SENDFILE to be true.  If the actual machine doesn't have sendfile,
then ap_sendfile will return APR_ENOTIMPL at this point, and Apache will
have to deal with it.  But Apache will have to deal with that case
anyway, because if a Unix machine doesn't support sendfile, and
iol->sendfile is called we will return APR_ENOTIMPL.

Windows NT and 2000 support sendfile, so they will return APR_SUCESS, and
actually write the data.  Windows 95/98 don't, so they will return
APR_ENOTIMPL.  Their performance will not be quite as good, but it won't
be that bad, because they won't actually DO anything.

Any other platform that makes decisions at run-time instead of compile
time will have problems using autoconf, so they will have to define their
own apr.h, at which point they can decide whether their base platform
should have APR_HAS_SENDFILE on or off.

Does that make sense?


> I proposed a test (ugly, certainly) for ((iol_socket *)viol)->sock
> or returning APR_ENOTIMPL if it's null, with a macro for
> APR_MAY_HAVE_SENDFILE (ugly, again).  That would avoid the runtime
> test for platforms that are known supporters or disavowers of 
> sendfile.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message