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 would much rather have APR default to not using the native sendfile, and only enable native sendfile when we have a lot of evidence that it does work correctly. Ryan On Fri, 18 Mar 2005 08:07:01 -0800, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: > --On Friday, March 18, 2005 5:59 AM -0500 Jeff Trawick <[EMAIL PROTECTED]> > wrote: > > > ...snip, snip... > > AIX: > > > > Doesn't really fail in the normal sense of not putting the right data > > on the wire, but can trigger a kernel memory issue if some kernel > > tuning is incorrect. So always fail if the APR_SENDFILE_AUTODETECT is > > on. (This kernel tuning is irrelevant unless sendfile or more obscure > > TCP usage is actually occuring, so the tuning issue has typically been > > there all along without hurting anything.) > > Is the kernel turning incorrect on AIX by default? Will this be fixed in some > future releases? You could do lots of things to corrupt your kernel by tuning > in other ways - so unless this is by default, I can't see why we should block > this. > > > ...snip, snip... > > +1 to this list of exceptions and adding a new flag called APR_SENDFILE_CHECK > (or APR_SENDFILE_AUTODETECT) to apr_socket_sendfile. -- justin > -- Ryan Bloom [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
