Thanks a lot! Actually, it works just as I expected, but I still have a couple of questions:
1. You say that we rely on the event model to call r->write_event_handler . But if r->write_event_handler is our handler, then we should handle this state, no? Meaning, if a send function returns NGX_AGAIN, we should handle some kind of a "busy bufs" state and call the write function with NULL.
2. How can you hold back reading more data from the data source?
On Friday, April 19, 2013 2:03:18 AM UTC+3, agentzh wrote:
Hello!
On Thu, Apr 18, 2013 at 11:15 AM, aviram wrote:
> I'm currently using (in my C code) the function ngx_http_lua_send_chain_link
> to send chain links to the client.
> This usually works well, but when it returns NGX_AGAIN, it gets a bit
> complicated.
>
> ngx_http_lua_send_chain_link calls ngx_http_output_filter, which is the
> function that returns this value.
> From viewing Nginx modules' code, it seems that the proper way to handle
> this error is to wait until Nginx gives us more run time, and then call
> ngx_http_output_filter with the value NULL as the chain link, repeating this
> process until ngx_http_output_filter returns NGX_OK.
>
Usually we just ignore the NGX_AGAIN code returned from the output
body filter chain.
In case of strict non-buffered processing, we may want to hold back
further outputs when we run out of buffers.
Basically, we rely on the Nginx event model to call
r->write_event_handler to flush out more pending outputs buffered in
the output filter chain by feeding NULL as the chain link to
ngx_http_output_filter.
Downstream output in Nginx is an asynchronous operation per se. To
implement synchronization in strict non-buffered outputing mode, we
need to hold back reading more data from the data source (usually, the
upstream) ourselves.
Hopefully I've made it clear for you :)
Best regards,
-agentzh
