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: svn commit: r1066944 - in /httpd/httpd/trunk: CHANGES configure.in server/main.c
Date Fri, 04 Feb 2011 21:51:26 GMT
On 2/4/2011 3:47 PM, Jim Jagielski wrote:
> On Feb 4, 2011, at 4:29 PM, William A. Rowe Jr. wrote:
>> 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.
> ++1 for some way of handling the fragmentation... of course,
> we could just switch to pocore for the memory stuff in APR.  :)

Which helps for apr_allocator but not for the internal fragmentation within
individual pools.  An optional pocore feature for APR 2 sounds great, patches
welcome :)

View raw message