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@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
