<div dir="ltr"><div><div><div><div>Hi all,<br><br></div>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.<br><br></div>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.<br><pre class="gmail-filecontent"><span class="gmail-comment">/* we use ngx_cycle->log because c->log was in c->pool */</span></pre>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()?<br><br></div>Cheers,<br></div>Lawrence<br><div><div><div><div><br>[1] <a href="http://lxr.nginx.org/source/src/http/modules/ngx_http_upstream_keepalive_module.c?v=nginx-1.10.1#0441">http://lxr.nginx.org/source/src/http/modules/ngx_http_upstream_keepalive_module.c?v=nginx-1.10.1#0441</a><br><div><br><br></div></div></div></div></div></div>