apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: svn commit: r1066944 - in /httpd/httpd/trunk: CHANGES configure.in server/main.c
Date Fri, 04 Feb 2011 21:47:27 GMT

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.  :)

View raw message