help with issue related to ngx_peer_connection_t, and ngx_unix_recv() returning NGX_AGAIN

[Maxim Dounin]

Hello!

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.

-- 
Maxim Dounin
http://nginx.org/en/donation.html