<html><body><div>Valentin,<br></div><div><br data-mce-bogus="1"></div><div>By reuse, you're suggesting that I size the array big enough for my expected usage and then implement reuse by tracking "in-use" versus "free" entries and avoid calling ngx_array_push each time a new entry is used.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I'm already doing this, I was just hoping to start out with a small array size and then have it grow depending on use case of HTTP requests. So the array may start out with 10 entries, but then if 100 requests come in, it'll grow. My particular use case shouldn't ever expose the leak because the array won't ever be big enough to exceed a pool block allocation of the page size (4096). Further if my module uses its own pool with a single block of 4096, I would be free to call ngx_array_push() and leaks within that block wouldn't affect any other modules or the system.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I was taking this as an opportunity to learn about the ngx_array_t and was confused when I saw how the memory was being managed in the grow case.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks for the prompt explanations!<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Joel</div><div><br>On Oct 28, 2015, at 10:49 AM, "Valentin V. Bartenev" <vbart@nginx.com> wrote:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">On Wednesday 28 October 2015 15:24:39 Lev Brouk wrote:<br><blockquote type="cite" class="quoted-plain-text">Valentin and Joel,</blockquote><blockquote type="cite" class="quoted-plain-text">It would appear that a part of Joel's (and my own) concern could be alleviated if ngx_array_push called ngx_pfree on the old memory block after it grew it in <a href="https://github.com/nginx/nginx/blob/master/src/core/ngx_array.c#L76" data-mce-href="https://github.com/nginx/nginx/blob/master/src/core/ngx_array.c#L76">https://github.com/nginx/nginx/blob/master/src/core/ngx_array.c#L76</a>. I understand that (a) doing this would still leak all the "small" allocs, and (b) ngx_pfree call is potentially slow since it walks the chain of large allocations in the pool. But that could be an option, perhaps?</blockquote><br>We usually don't have so big arrays in nginx that ngx_pfree can free.<br>So, calling it will be waste of CPU cycles most of the time.<br><br><blockquote type="cite" class="quoted-plain-text">That aside, I too am wondering what memory management options (other than malloc) are available for data structures with long lifespans, or if there are any relevant development plans. It is certainly appealing to be able to use ngx_array_t and ngx_list_t in these "long-lived" use-cases.</blockquote><br>AFAIK, no any dev plans at the moment. I'd suggest just to implement<br>some simple reuse mechanism for your data structures. That's what<br>nginx does for its chains and buffers that are reused during the<br>processing of request.<br><br> wbr, Valentin V. Bartenev<br><br>_______________________________________________<br>nginx-devel mailing list<br><a href="mailto:nginx-devel@nginx.org" data-mce-href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br><a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" data-mce-href="http://mailman.nginx.org/mailman/listinfo/nginx-devel">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br></span></div></div></blockquote></div></div></body></html>