Persistent buffers allocation

[Maxim Dounin]

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/