httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r729538 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_scgi.xml modules/mappers/mod_rewrite.c modules/proxy/config.m4 modules/proxy/mod_proxy_scgi.c
Date Sun, 28 Dec 2008 09:44:07 GMT


On 12/27/2008 10:55 PM, Paul Querna wrote:
> Ruediger Pluem wrote:
>>
>> On 12/27/2008 10:39 PM, Paul Querna wrote:
>>> Ruediger Pluem wrote:
>>>> On 12/27/2008 07:27 PM, André Malo wrote:
>>>>> * Ruediger Pluem wrote:
>>>>>
>>>>>> On 12/27/2008 04:07 PM, André Malo wrote:
>>
>>>>> Isn't that private config?
>>>> At least it is one of another module. And yes I agree if there is no
>>>> official
>>>> API to get the setting of d->enable_mmap (currently too lazy to check
>>>> this) it
>>>> is the best to stay with the subrequest approach.
>>> This is a general flaw with hoe things like EnableMMAP and
>>> EnableSendfile work -- we really should have an API that passes in a
>>> filepath to test for each attribute, because right now when you insert
>>> the buckets into the brigade, you need to enable sendfile and mmap on
>>> creation, and the core filters won't disable them even if they are
>>> disabled.
>>
>> I agree, but I think that the sendfile case is already handled by the
>> core filter and only the MMAP case needs our attention here. The MMAP
>> case
>> needs attention at the point of time we insert the file bucket as any
>> subsequent
>> read on this bucket already starts the MMAP conversion in contrast to
>> sendfile
>> where this decision only matters until we really go on the wire (in
>> the core output
>> filter).
> 
> The sendfile case is not handled by the core filter, I had to work
> around this in a closed source module this fall. (Why isn't this
> working, I put EnableSendfile off in the config file for this samba
> share path!)

Ah, sorry. My bad. I have not read the core filter code closely enough.
Whether to use sendfile or not is a property of the fd in a file bucket
and this is set of course even *before* inserting the file bucket into
the brigade.

Even more bad: Once this flag is set you cannot change it any longer on an
existing apr_file_t struct. Possibly something that should change in APR 1.4.x.
I am not sure if it should be possible to modify all flags of an
apr_file_t struct after an open or just the APR_SENDFILE_ENABLED
flag. I guess limiting this to APR_SENDFILE_ENABLED is more safe.

Regards

Rüdiger



Mime
View raw message