ngx_array.c allocation question

[Lev Brouk]

Valentin and Joel,
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 https://github.com/nginx/nginx/blob/master/src/core/ngx_array.c#L76. 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?
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.
- Lev 


     On Wednesday, October 28, 2015 6:43 AM, Valentin V. Bartenev <vbart at nginx.com> wrote:
   

 On Tuesday 27 October 2015 22:51:53 Joel Cunningham wrote:
> Request pools seem short lived, but the cycle pool sticks around for a long time.
> 
> 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.
> 
> 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.
> 
[..]

It's an intentional design decision.  Moreover, there's no easy way
to return memory to pool.  Even ngx_array_destroy() returns memory
only in very specific case, when the destruction is happened right
after the allocation, so it works only for some temporary arrays.

  wbr, Valentin V. Bartenev

_______________________________________________
nginx-devel mailing list
nginx-devel at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20151028/9fce6061/attachment.html>