Yichun Zhang

I'm also worried that according to the current rwlock implementation, the writers may never have a chance to obtain the lock (at least before too long) when a continuous flow...

@sitano Thanks for the patch and I understand this is more useful. However, your change breaks the existing test suite. I'm getting these failures: https://gist.github.com/agentzh/adf13526aa1625d7e50b Will you update the test...

@hkmo Please use the `ngx-releng` script to analyze coding style issues in your branch. See https://github.com/openresty/openresty-devel-utils/blob/master/ngx-releng

Also, please rebase to the latest master.

@hkmo They were the consequences of the earlier compilation errors. To quote: ``` /home/travis/build/openresty/lua-nginx-module/src/ngx_http_lua_output.c: In function ‘ngx_http_lua_ffi_write’: /home/travis/build/openresty/lua-nginx-module/src/ngx_http_lua_output.c:823:16: error: ‘NGX_HTTP_LUA_FFI_NO_REQUEST’ undeclared (first use in this function) return NGX_HTTP_LUA_FFI_NO_REQUEST; ^ /home/travis/build/openresty/lua-nginx-module/src/ngx_http_lua_output.c:823:16:...

@ethnext Are you using any 3rd-party Lua C modules or 3rd-party nginx C modules that are not maintained by OpenResty? It seems like a memory corruption of Lua string objects....

@ethnext You know that the `socket.http` module from the LuaSocket library is blocking horribly in the context of OpenResty?

@ethnext It would be much easier if you can provide a minimal and standalone example that can (relatively) reliably reproduce the issue on our side :) Please see http://openresty.org/en/faq.html#how-should-i-report-a-problem

@ethnext Also, please always provide the version numbers of the related software you're using (OpenResty, nginx, ngx_lua, lua-resty-redis, operating system, and etc).

socket.http always blocks even in ngx.timer.at. If socket.http has memory corruptions, it can surely lead to the problem your are seeing now.