Connection API?

Maxim Dounin mdounin at
Mon Dec 3 17:31:52 UTC 2012


On Mon, Dec 03, 2012 at 03:57:24PM +0000, Nick Kew wrote:

> On Mon, 3 Dec 2012 18:42:48 +0400
> Maxim Dounin <mdounin at> wrote:
> > As of now connection end may be hooked by using connection's pool 
> > cleanup handler.  There is no connection start hook in the current 
> > http module API.
> > 
> > It's probably worth adding, but I doubt we need full-featured API 
> > here.  In particular, full ctx array would be huge compared to a 
> > connection structure size which is kept small to minimize 
> > keepalive connections costs.  And the demand for a connection start 
> > hook looks extremelay low.
> Thanks for the reply.  You mean you're happy to add a new-connection
> hook, but not a context?

Something like this.  I would like to see use case first though, 
to make sure it indeed requires connection start hook.

Simple way to store module-specific per-connection data without 
ctx array I could think of is something based on connection pool 
cleanup handler.  I.e. one can register connection pool cleanup 
handler, and then find associated data by iterating over 
connection pool cleanup handlers installed.

It will be more costly than lookup via ctx array, but shouldn't be 
too costly as there shouldn't be more than one such lookup per 
request and I expect only few such modules.  Data lookup will be 
also free in connection pool cleanup handler itself.

> In an HTTP context I can work around that: my module maintains a
> pool of connection contexts, and associates each new HTTP request
> with its connection in a post_read_request hook.
> Can I assume that if requests r1 and r2 come on the same connection
> then r1->connection == r2->connection?  That would enable me to save
> a little overhead by using the connection pointer as a hash key,
> rather than having to compute a key from the connection data.

As of now its always true.  Note though, that with SPDY patches 
Valentin is working on it will likely change.  I've just talked to 
him and he suggests to compare r[12]->connection->fd instead as a 
more bulletproof solution.

Maxim Dounin

More information about the nginx-devel mailing list