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