apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] Sendfile API compatibility breakage
Date Tue, 11 Feb 2003 21:40:31 GMT
At 12:54 PM 2/11/2003, you wrote:
>William A. Rowe, Jr. wrote:
>>I'm very close to an outright veto of such a change, at this time...
>
>forget it.
>
>Not only is the binary interface to sendfile broken now, the source interface is broken
too.  Since there was no mmn bump, there is no reasonable way a module which ships independently
from the core can write code to enable sendfile with the new interface and expect the module
to compile against 2.0.43 or earlier.
>
>I like the concept of disabling sendfile at runtime to handle the corner cases like nfs
and broken OSes.  No argument there.  But the existing code goes beyond that.  As things stand
now, non-core module owners are screwed if they want to use sendfile in the majority of cases
where it works fine.

I suggest the following as a friendly compromise to avoid voting... introduce 
DISABLE, don't drop ENABLE (especially since your patch would *reverse* 
the meaning of the EnableSendfile directive for httpd 2.0.44 built against 
a newer apr!!!)  Respect both flags unless both are passed to apr_file_open.

If neither is specified, let the platform author of the apr_sendfile() code decide
how *safe* it is to enable the feature.  This could include context (such as
the filesystem if they want to query it) or filesize (<2gb) or whatever choices
are wise.

ENABLE and DISABLE would both be explicit overrides to any sanity tests.
Based on current bugzilla reports, httpd EnableSendfile should gain the
'default' state.  So we could turn it on or off, or leave it up to APR.

Bill 


Mime
View raw message