Hello! On Thu, Aug 22, 2019 at 02:11:18PM +0000, Eran Kornblau wrote:
> Hi all, > > I noticed today that I'm missing something basic... I wanted to allocate some > buffers that will live throughout the lifetime of the process = > not associated with any specific request. I believe I've already done > something like that in the past, and I used the cycle pool for that. > However, after digging a bit in the code, I found that in single process > mode, if nginx is reloaded, a new cycle is created and the > old one destroyed. > > If my understanding is correct, this has many implications far exceeding the > simple question I started with... > For example, since the configuration is allocated on the cycle pool, it means > that modules should not read the configuration > of the request in any asynchronous callback, because there is a chance that > the configuration was already freed since the request > object was created. > > I then found this issue - https://trac.nginx.org/nginx/ticket/945 so I guess > that this problem is known and ignored because > 'master_process off' is only for dev, and no need to support reload there... > > So, back to my original question... is using ngx_cycle->pool the correct way > to allocate such "persistent" buffers? > Another option is to use ngx_alloc directly (if the process quits, it doesn't > matter...), but cycle pool sounds a bit more elegant > (and won't have valgrind report leaks...) Using cycle's pool is usually a way to go. Note though, that depending on the particular point your code does the allocation, using ngx_cycle->pool might be wrong. For example, during configuration parsing ngx_cycle points to the previous cycle, not the current one, and you have to use cf->cycle->pool instead (or cf->pool, which is the same). -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
