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