Sander Striker wrote:
To be honest changing sms_trivial to use malloc instead of apr_sms_malloc is
an easy move (just a few lines to change) so it's probably worth trying and then seeing what we get...
Massive leakage :)
Remember how the apr_sms_reset code works; it does not have to traverse and destroy all children since they all use the memory from that sms.
I propose that it's better to not optimize for reset.
With all the fragmentation I'm seeing in the httpd, the number of blocks managed by an SMS in the middle of a stack can be larger than the number of blocks that its descendants would have to manage (and free upon destruction) if they got memory from a block source themselves. Thus we'd likely have _less_ work to do upon reset if the SMS being reclaimed had to recurse through its descendants and ask them to return their blocks by themselves (because the total number of blocks being returned to SMSs further down the stack would be smaller).
This problem would go away, of course, if the memory management strategy employed by the parent SMS were one that didn't cause so much fragmentation. But I don't see a way to accomplish that without slowing down allocation.
--Brian
