Event-driven handler

Ryan Dahl ry at tinyclouds.org
Wed Feb 18 23:32:05 MSK 2009

> [handler] (as mentioned before)
> - passes off request to content generator
> - returns immediately to Nginx with NGX_DONE
> [content generator]
> - generates content
> - in threadsafe fashion, puts the output content in a queue of responses to
> be returned

what is the content generator? are you writing it from scratch? if it
connects to external sockets and doesn't use nginx's event loop or is
blocking  - it should be an external process and you should use an
upstream module. if you are writing from scratch (that is all of the
socket code too) you are possibly not on the wrong path (unlikely)

> [in Nginx]
> - loop that checks every e.g. 0.001 secs to see if there are any responses

this is going to fail spectacularly.

> (headers and/or content)
> - checks for responses in threadsafe fashion, and if there are, calls
> ngx_http_output_filter etc

You should be talking via pipes/sockets to your content generator and
getting callbacks on those via the event loop.    And if you're
talking to another thread via pipes already you might as well save the
trouble and move it into its own process and use the already written
mature upstream modules. Just compiling a bunch of random code into
Nginx is not going to make it fast.  You either design it from the
ground up very carefully or use external processes.

More information about the nginx mailing list