<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10px"><div id="yui_3_16_0_1_1446043754328_8557"><span id="yui_3_16_0_1_1446043754328_9164">Valentin and Joel,</span></div><div id="yui_3_16_0_1_1446043754328_8557"><span><br></span></div><div id="yui_3_16_0_1_1446043754328_8557" dir="ltr"><span id="yui_3_16_0_1_1446043754328_8755">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" id="yui_3_16_0_1_1446043754328_8756">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?</span></div><div id="yui_3_16_0_1_1446043754328_8557" dir="ltr"><span><br></span></div><div id="yui_3_16_0_1_1446043754328_8557" dir="ltr"><span id="yui_3_16_0_1_1446043754328_9283">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.</span></div><div id="yui_3_16_0_1_1446043754328_8557" dir="ltr"><span><br></span></div><div id="yui_3_16_0_1_1446043754328_8557" dir="ltr"><span>- Lev</span></div> <br><div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 10px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font size="2" face="Arial"> On Wednesday, October 28, 2015 6:43 AM, Valentin V. Bartenev <vbart@nginx.com> wrote:<br> </font> </div> <br><br> <div class="y_msg_container">On Tuesday 27 October 2015 22:51:53 Joel Cunningham wrote:<br clear="none">> Request pools seem short lived, but the cycle pool sticks around for a long time.<br clear="none">> <br clear="none">> I'm working on a custom module that has state which should persist the entire uptime of NGINX. I was going to use an array allocated out of the cycle pool, but now I'm not sure that's a good idea. My array could grow and potentially leak memory in the cycle pool. Maybe the cycle pool allocation is big enough we never actually exceed the allocation and each array grow will continue to use the current allocation? Default size is 16KB. My module could have its own pool, but the same leak could happen within that.<br clear="none">> <br clear="none">> Would you say this was an intentional design decision or a bug? Doesn't look like it would be hard to fix assuming my understanding of ngx_array.c is correct.<br clear="none">> <br clear="none">[..]<br clear="none"><br clear="none">It's an intentional design decision. Moreover, there's no easy way<br clear="none">to return memory to pool. Even ngx_array_destroy() returns memory<br clear="none">only in very specific case, when the destruction is happened right<br clear="none">after the allocation, so it works only for some temporary arrays.<div class="yqt7287459300" id="yqtfd80024"><br clear="none"><br clear="none"> wbr, Valentin V. Bartenev<br clear="none"><br clear="none">_______________________________________________<br clear="none">nginx-devel mailing list<br clear="none"><a shape="rect" ymailto="mailto:nginx-devel@nginx.org" href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br clear="none"><a shape="rect" href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>