Inconsistent order for ngx_destroy_pool() and ngx_close_connection()

[Lawrence Stewart]

Hi all,

I need to pull kernel data using getsockopt() for a connection prior to the
socket being closed. A pool cleanup handler registered with the
ngx_connection_t's pool would seem to be the right way to do this, but
ngx_http_close_connection() calls ngx_close_connection() prior to
ngx_destroy_pool(), which means my cleanup handler sees a closed socket.

A look through ngx_close_connection() and the functions it calls would lead
me to believe it should be safe (and possible even desirable in an ordering
sense) to destroy the connection's pool prior to calling
ngx_close_connection(). There is an existence proof in the nginx tree that
this is reasonable to do (see [1]) and there is also a comment in
ngx_close_connection() that implies it expects that the connection's pool
has already been destroyed i.e.

/* we use ngx_cycle->log because c->log was in c->pool */

Are there some subtleties I'm missing, or is it correct and reasonable to
always call ngx_destroy_pool() on a connection's pool prior to calling
ngx_close_connection()?

Cheers,
Lawrence

[1]
http://lxr.nginx.org/source/src/http/modules/ngx_http_upstream_keepalive_module.c?v=nginx-1.10.1#0441
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20161003/3d1383ea/attachment.html>