httpd-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: svn commit: r1066944 - in /httpd/httpd/trunk: CHANGES configure.in server/main.c
Date Fri, 04 Feb 2011 21:29:36 GMT
On 2/4/2011 3:26 PM, Jim Jagielski wrote:
> 
> On Feb 4, 2011, at 4:14 PM, William A. Rowe Jr. wrote:
> 
>> On 2/4/2011 2:54 PM, Stefan Fritsch wrote:
>>>>
>>>> +1 here as well, if this is to be addressed at all, the portability
>>>> layer seems like the correct place to do it, if desired by the
>>>> app.
>>>
>>> Would you prefer os/unix or APR? I am also happy to simply revert if 
>>> that is the majority opinion.
>>
>> I suspect that a generic apr '_refresh' function would be most useful
>> across the board, others might disagree.
>>
> 
> Isn't APR for "portability"? All I see is a single function
> call... 
> 
> If we have to pollute something with this res_init(), then httpd
> is likely the better place than expanding APR even more beyond
> being a "simple" portable runtime ;)
> 
> But I'm fine either way... as long as it builds and links ;)

My thought is that this might not be the only thing to 'refresh' when
you have an app which needs current state.  It would be a chance to
flush out all caches and set the state basically to apr_initialize(),
modulo any open resources or currently allocated pools.  It could even
go so far as to free() all the unused pool memory, giving us a really
fresh start on heap pages that have been fragmented to heck.

Mime
View raw message