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