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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel