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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
