请教openresty中request处在lua协程的概念

9cseer · 2016-09-03T18:49:29+00:00

Hi,设计如此`kill -QUIT nginx.pid`是nginx的特性了, 优雅地停止nginx, &#x537...

请教openresty中request处在lua协程的概念

9cseer

在openresty文档中提到每个request是在lua的协程中进行处理从而有请求隔离的效果，那么请问一下request是只要进入lua环境就处于协程中还是如lua nginx文档中提及某些指令会进入协程中进行处理？
也就是说request在lua协程中只是在某些特定的指令才会出现。这样理解正确吗？

agentzh

Hello!

2016-09-03 3:49 GMT-07:00  9cseer:
> 在openresty文档中提到每个request是在lua的协程中进行处理从而有请求隔离的效果，那么请问一下request是只要进入lua环境就处于协程中还是如lua nginx文档中提及某些指令会进入协程中进行处理？
> 也就是说request在lua协程中只是在某些特定的指令才会出现。这样理解正确吗？
>

content_by_lua*, rewrite_by_lua*, access_by_lua*,
ssl_certificate_by_lua*, ssl_session_fetch_by_lua* 这些 Lua handler
只要一进入就会处于一个 Lua coroutine 之中（或者说，处于一个 Lua 轻量级线程中）。其他配置指令则不然，比如
header_filter_by_lua* 和 balancer_by_lua*，所以这些没有 Lua coroutine 环境的 Lua
handler 都不支持 cosocket 和 ngx.sleep 这样需要 yield 的 Lua API.

Regards,
-agentzh

9cseer

在 2016年9月5日星期一 UTC+8上午3:30:13，agentzh写道：

Hello!

2016-09-03 3:49 GMT-07:00 9cseer:
> 在openresty文档中提到每个request是在lua的协程中进行处理从而有请求隔离的效果，那么请问一下request是只要进入lua环境就处于协程中还是如lua nginx文档中提及某些指令会进入协程中进行处理？
> 也就是说request在lua协程中只是在某些特定的指令才会出现。这样理解正确吗？
>

content_by_lua*, rewrite_by_lua*, access_by_lua*,
ssl_certificate_by_lua*, ssl_session_fetch_by_lua* 这些 Lua handler
只要一进入就会处于一个 Lua coroutine 之中（或者说，处于一个 Lua 轻量级线程中）。其他配置指令则不然，比如
header_filter_by_lua* 和 balancer_by_lua*，所以这些没有 Lua coroutine 环境的 Lua
handler 都不支持 cosocket 和 ngx.sleep 这样需要 yield 的 Lua API.

Regards,
-agentzh

春哥，thanks a lot for comments and help，

Spring

a958000432

On Monday, September 5, 2016 at 3:30:13 AM UTC+8, agentzh wrote:

Hello!

2016-09-03 3:49 GMT-07:00 9cseer:
> 在openresty文档中提到每个request是在lua的协程中进行处理从而有请求隔离的效果，那么请问一下request是只要进入lua环境就处于协程中还是如lua nginx文档中提及某些指令会进入协程中进行处理？
> 也就是说request在lua协程中只是在某些特定的指令才会出现。这样理解正确吗？
>

content_by_lua*, rewrite_by_lua*, access_by_lua*,
ssl_certificate_by_lua*, ssl_session_fetch_by_lua* 这些 Lua handler
只要一进入就会处于一个 Lua coroutine 之中（或者说，处于一个 Lua 轻量级线程中）。其他配置指令则不然，比如
header_filter_by_lua* 和 balancer_by_lua*，所以这些没有 Lua coroutine 环境的 Lua
handler 都不支持 cosocket 和 ngx.sleep 这样需要 yield 的 Lua API.

Regards,
-agentzh

春哥你好，

我有一个疑问，比如在运行content_by_lua*的代码，此时就进入了一个Lua coroutine中，假定这个coroutine名字叫A。那么我在coroutine A调用lua-ngx-module coroutine的api有创建一个协程B，因为B需要调用resume切换到协程A中。是不是说协程B的调度是在协程A的管理下，ngx lua的模块只是会调度A这种有ngx lua模块创建出来的协程，但是协程A中调用coroutine api创建出来的协程不是由ngx lua模块调度的？

按照我的理解，content_by_lua*创建出来的协程，相当于操作系统中进程，由ngx lua模块中的操作系统进行调度，在这个进程中，调用 coroutine api创建的协程，需要自己在代码逻辑中进行调度，主动yield出控制权。

wyj1017146866

你完全理解反了，lua的协程连thread都不是，是比用户级线程还要轻的，内核和宿主根本不知道它们的存在。

如果要跨请求通信的话，需要跨worker process的话可以用shared,但是shared只能轮询，不能通知。
如果可以只有一个worker process的话，可以用semaphore来实现通知，用变量实现跨请求通信。

nickxiao

尝试回答一下这个问题:

content_by_lua_block {

	local B = coroutine.create(function (n)

	      print('in co', coroutine.yield(n, 'more'))

	end)

	coroutine.resume(co, 'a')

	ngx.say('done')

}

B 虽然是 A 调用 coroutine.create() 创建出来的. 但级别和 A 一样. 他们都是当前 worker 全局 lua vm 的 light-thread. 下面的代码说明了这一点:

/* ngx_http_lua_coroutine_create_helper() in ngx_http_lua_coroutine.c */

...

vm = ngx_http_lua_get_lua_vm(r, ctx);

/* create new coroutine on root Lua state, so it always yields

* to main Lua thread

co = lua_newthread(vm);

正如 comments 里说的, B yield 的时候也会回到 nginx 的事件循环的代码. 确切的说是 ngx_http_lua_run_thread()函数中. 其中根据返回值判断, 会将 A 设置为 ctx->cur_co_ctx, 再次调用 lua_resume(), 这时, coroutine.resume() 返回, 代码继续执行 ngx.say().

所以, 即使 A (被称为 entry coroutine) 执行完成了, 如果 B 还在运行, 那么这个 http request content 阶段也不会结束, 直到该 request 下所有的 light-thread 退出.

另外, ngx_lua 中没有实现调度器, 只是借助 nginx 的事件模块, 由网络/定时器触发来调度 light-thread.

./nickr

On Nov 16, 2018, at 11:04 AM, jiancai Lee <a958...@gmail.com> wrote:

On Monday, September 5, 2016 at 3:30:13 AM UTC+8, agentzh wrote:
Hello!

2016-09-03 3:49 GMT-07:00 9cseer:
> 在openresty文档中提到每个request是在lua的协程中进行处理从而有请求隔离的效果，那么请问一下request是只要进入lua环境就处于协程中还是如lua nginx文档中提及某些指令会进入协程中进行处理？
> 也就是说request在lua协程中只是在某些特定的指令才会出现。这样理解正确吗？
>

content_by_lua*, rewrite_by_lua*, access_by_lua*,
ssl_certificate_by_lua*, ssl_session_fetch_by_lua* 这些 Lua handler
只要一进入就会处于一个 Lua coroutine 之中（或者说，处于一个 Lua 轻量级线程中）。其他配置指令则不然，比如
header_filter_by_lua* 和 balancer_by_lua*，所以这些没有 Lua coroutine 环境的 Lua
handler 都不支持 cosocket 和 ngx.sleep 这样需要 yield 的 Lua API.

Regards,
-agentzh

春哥你好，
我有一个疑问，比如在运行content_by_lua*的代码，此时就进入了一个Lua coroutine中，假定这个coroutine名字叫A。那么我在coroutine A调用lua-ngx-module coroutine的api有创建一个协程B，因为B需要调用resume切换到协程A中。是不是说协程B的调度是在协程A的管理下，ngx lua的模块只是会调度A这种有ngx lua模块创建出来的协程，但是协程A中调用coroutine api创建出来的协程不是由ngx lua模块调度的？
按照我的理解，content_by_lua*创建出来的协程，相当于操作系统中进程，由ngx lua模块中的操作系统进行调度，在这个进程中，调用 coroutine api创建的协程，需要自己在代码逻辑中进行调度，主动yield出控制权。

--
--