help with issue related to ngx_peer_connection_t, and ngx_unix_recv() returning NGX_AGAIN
mdounin at mdounin.ru
Sat Aug 17 01:59:25 UTC 2013
On Thu, Aug 15, 2013 at 11:25:24PM +0200, Abbot, Drew wrote:
> That approach seemed ok at first, but I've been noticing strange
> behavior on the non-blocking sockets within my_read_handler().
> In particular, I call ngx_unix_recv() in my_read_handler() to
> actually receive data, but in any given invocation of
> my_read_handler(), the first call to ngx_unix_recv() never ends
> up reading more than 128 bytes, and the second call always
As your followup message suggests, 128 bytes is probably due to
socket buffer sizes you use.
> returns NGX_AGAIN, as if no more data were available at that
> time. However, I know more data is available! For example, if
> I continue to call ngx_unix_recv() is a loop, ngx_unix_recv()
> will return NGX_AGAIN forever, even though more data will
> definitely be available! It's not until a separate invocation
First of all, you shouldn't call ngx_unix_recv() directly - you
should call c->recv() instead.
Second, you are not expected to call c->recv() again after it
returns NGX_AGAIN - you should call ngx_handle_read_event()
instead, and wait for a read handler to be called again.
If a call returns NGX_AGAIN, nginx in some cases will just return
NGX_AGAIN on subsequent calls, without an actual recv() syscall -
in particular, this happens with kqueue event method where number
of bytes available is reported by kevent(). See
src/os/unix/ngx_recv.c for details.
More information about the nginx-devel