websocket只能在创建它的request里做收发吗？

fatfatson

https://medium.com/p/1778601c9e05

使用这个文章里的例子，是正常的。

但是，我在websocket创建后，启动一个定时器，在那里面给它发数据：

setInterval = function(delay, func)

local handler

handler = function (premature)

if premature then return end

local r = func()

if r==true then return end

local ok, err = ngx.timer.at(delay, handler)

if not ok then

ngx.log(ngx.ERR, "failed to create the timer: ", err)

return

end

local ok, err = ngx.timer.at(delay, handler)

if not ok then

ngx.log(ngx.ERR, "failed to create the timer: ", err)

return

end

local server = require "resty.websocket.server"

local wb, err = server:new{

timeout = 5000,

max_payload_len = 65535

}

if not wb then

ngx.log(ngx.ERR, "failed to new websocket: ", err)

return ngx.exit(444)

end

--在这里创建一个timer给socket发数据

setInterval(2,function()

local bytes, err = wb:send_text("timer....")

--print("timer....")

end)

结果就提示错误：

2014/01/26 17:40:04 [error] 46130#0: *52 [lua] websocket.lua:41: failed to receive frame: nil, client: 127.0.0.1, server: , request: "GET /api/websocket HTTP/1.1", host: "127.0.0.1:8080"

难道websocket只能在创建它的ctx里做收发？

那实际使用中，对于一个简单的2人聊天的例子，两个客户端各连上来，各有一个while true do RECV逻辑在跑，怎么在收到自己客户端发上来的信息时，发给另一个socket呢？

fatfatson

翻了下以前的帖子，好像是说websocket也是cosocket，不能在创建它的ctx之外使用。

那这样的话，使用起来就很受限了噢，“只能在创建它的ctx里用”，那不是意味着，只能是“收－发－收－发”这样的序列？服务器想主动发点东西下去还不行？

fatfatson

感觉要解决这问题的话，只有让其它逻辑把要发的消息存到某个队列里去，等待相应websocket的request线程去读然后自己发下去

但是按上面那种写法，这些request线程是用while true do RECV死等的，要让它在等网络数据的同时还能等待某个消息队列已满的事件，也就是类似libevent里同时监听多个事件那样的行为，目前openresty里是做不到吧？

再退一步就只有减小recv的timeout，让它尽快返回，以便去检查消息队列了，但是这样就增加了空转的消耗

总之，不知道该怎么做才好。。

大神们指点下吧。。。

agentzh

Hello!

2014/1/26 小冶:
> 感觉要解决这问题的话，只有让其它逻辑把要发的消息存到某个队列里去，等待相应websocket的request线程去读然后自己发下去
> 但是按上面那种写法，这些request线程是用while true do
> RECV死等的，要让它在等网络数据的同时还能等待某个消息队列已满的事件，也就是类似libevent里同时监听多个事件那样的行为，目前openresty里是做不到吧？
> 再退一步就只有减小recv的timeout，让它尽快返回，以便去检查消息队列了，但是这样就增加了空转的消耗
> 总之，不知道该怎么做才好。。

即将合并到 ngx_lua 中的双全工 cosocket 补丁将能解决这里的困难。它允许两个轻线程同时读写一个 cosocket 对象。见

    https://github.com/chaoslawful/lua-nginx-module/pull/290

当然，这个 pull request 里的补丁还包含了其他一些不相干的 cosocket 新特性。

Regards,
-agentzh

kytexzy

On Sunday, January 26, 2014 10:45:49 PM UTC+8, 小冶 wrote:

感觉要解决这问题的话，只有让其它逻辑把要发的消息存到某个队列里去，等待相应websocket的request线程去读然后自己发下去

我目前就是把消息放到一个消息缓冲区中，每一次loop中都去检查缓冲区中是否有消息，有的话就去出来再用websocket:sent_text发出去. 我想以后有了全双工的cosocket就不用这么做了.

但是按上面那种写法，这些request线程是用while true do RECV死等的，要让它在等网络数据的同时还能等待某个消息队列已满的事件，也就是类似libevent里同时监听多个事件那样的行为，目前openresty里是做不到吧？

我觉得同时监听多个事件可能要用到ngx.thread.spawn

再退一步就只有减小recv的timeout，让它尽快返回，以便去检查消息队列了，但是这样就增加了空转的消耗

空转应该木有问题，因为它不会阻塞ngx worker嘛!

总之，不知道该怎么做才好。。

fatfatson

谢春哥！

年后能合回来了吧？急切期盼中。

在 2014年1月27日星期一UTC+8上午5时22分52秒，agentzh写道：

Hello!

2014/1/26 小冶:
> 感觉要解决这问题的话，只有让其它逻辑把要发的消息存到某个队列里去，等待相应websocket的request线程去读然后自己发下去
> 但是按上面那种写法，这些request线程是用while true do
> RECV死等的，要让它在等网络数据的同时还能等待某个消息队列已满的事件，也就是类似libevent里同时监听多个事件那样的行为，目前openresty里是做不到吧？
> 再退一步就只有减小recv的timeout，让它尽快返回，以便去检查消息队列了，但是这样就增加了空转的消耗
> 总之，不知道该怎么做才好。。

即将合并到 ngx_lua 中的双全工 cosocket 补丁将能解决这里的困难。它允许两个轻线程同时读写一个 cosocket 对象。见

https://github.com/chaoslawful/lua-nginx-module/pull/290

当然，这个 pull request 里的补丁还包含了其他一些不相干的 cosocket 新特性。

Regards,
-agentzh

fatfatson

应该不是ngx.thread.spawn，多事件监听本身是操作系统级的api，应用层就是一个单线程循环处理就行了

另外，空转肯定增加消耗的，本来是没有事件就挂起的，现在频繁的没有-返回-重来，都白跑了，而且连接数量多起来了更可观。

agentzh

Hello!

2014/1/26 小冶:
> 应该不是ngx.thread.spawn，多事件监听本身是操作系统级的api，应用层就是一个单线程循环处理就行了

出于易用性方面的考虑，ngx_lua 在设计上故意不直接暴露底层的事件接口。毕竟在 Lua 层面上创建一堆的事件回调并不是一件有趣的事情。

所以在设计上，ngx_lua 使用多个“轻量级线程”的模型。这些“轻量级线程”都是基于 Lua coroutine
的，再多的“轻线程”都是运行在一个 OS 线程里面的。

另外，值得一提的是，你在设计请求间的数据交换时，需要注意 nginx 的多 worker 进程的通信模型（除非你只配置单个 nginx
worker，但那样的话，你的 nginx 服务器就只能利用到一个逻辑 CPU 核）。你在 Lua VM 里的数据是不能直接跨越当前
worker 进程的边界的。类似地，系统级别的 epoll/poll/select
事件也是不能直接跨域进程边界的。你需要自己设计这里的数据交换和共享策略（比如基于 ngx_lua 提供的共享内存字典，或者基于 redis
这样的外部共享服务）。当然，如果你的前端有多个 nginx 实例，就更要注意这里的请求分发和数据共享问题。

Regards,
-agentzh

fatfatson

春哥请教下：有没有办法把一个websocket连接“移交”给某个固定进程处理呢？比如说几个人开房间玩游戏的问题，肯定希望这个房间里的人都在一个进程里处理，但不同房间可以有不同的进程。首先房主建房时可以随机选进程，但后续进房的人，就希望把它们都移到房主的进程里。这个该怎么实现呢

在 2014年1月28日星期二UTC+8上午3时26分33秒，agentzh写道：

Hello!

2014/1/26 小冶:
> 应该不是ngx.thread.spawn，多事件监听本身是操作系统级的api，应用层就是一个单线程循环处理就行了

出于易用性方面的考虑，ngx_lua 在设计上故意不直接暴露底层的事件接口。毕竟在 Lua 层面上创建一堆的事件回调并不是一件有趣的事情。

所以在设计上，ngx_lua 使用多个“轻量级线程”的模型。这些“轻量级线程”都是基于 Lua coroutine
的，再多的“轻线程”都是运行在一个 OS 线程里面的。

另外，值得一提的是，你在设计请求间的数据交换时，需要注意 nginx 的多 worker 进程的通信模型（除非你只配置单个 nginx
worker，但那样的话，你的 nginx 服务器就只能利用到一个逻辑 CPU 核）。你在 Lua VM 里的数据是不能直接跨越当前
worker 进程的边界的。类似地，系统级别的 epoll/poll/select
事件也是不能直接跨域进程边界的。你需要自己设计这里的数据交换和共享策略（比如基于 ngx_lua 提供的共享内存字典，或者基于 redis
这样的外部共享服务）。当然，如果你的前端有多个 nginx 实例，就更要注意这里的请求分发和数据共享问题。

Regards,
-agentzh

agentzh

Hello!

2014-01-28 小冶:
> 春哥请教下：有没有办法把一个websocket连接“移交”给某个固定进程处理呢？

以自定义方式在 L7 层面上“移交”连接是绝对的高代价操作。这也是nginx 并没有提供控制单个请求由哪个 worker 进程来服务的机制的原因之一。

我觉得这里应当换一种思路，改“移交”连接为交换数据。这样即使两个下游连接位于不同的进程乃至不同的机器上时，它们之间仍能相互通信。

Regards,
-agentzh

fatfatson

再次请教下春哥：

如果考虑到请求会被随机分到不同的nginx进程去处理，那么在server端对websocket的收发处理，还真就只能是每个socket只由创建它的request去读写了，即使你说的那个双工补丁打上了，一个request ctx也不可能给另一个request的socket去发信息，因为两者可能根本不在同一进程。

那么两个socket之间要互发数据，只能是先把数据写到外部共享如redis里，通过自己约好的某种协议规则，每个request在while循环的每一帧里去检查获取，然后给自己的socket下发。

这样一来，就还是需要一个更高效的类epoll机制，即可以同时等待多种事件，比如自己socket有数据到达，或是外部存储有新数据填充，或者是共享内存里有新数据。

否则，仍然只能通过降低socket timeout的办法，使每一轮循环尽快结束，以避免错过可能早已填充好的外部数据（其它socket转过来的信息），但这样又加大了空转的频率，不知是否导致性能下降？

在 2014年1月28日星期二UTC+8上午3时26分33秒，agentzh写道：

Hello!

2014/1/26 小冶:
> 应该不是ngx.thread.spawn，多事件监听本身是操作系统级的api，应用层就是一个单线程循环处理就行了

出于易用性方面的考虑，ngx_lua 在设计上故意不直接暴露底层的事件接口。毕竟在 Lua 层面上创建一堆的事件回调并不是一件有趣的事情。

所以在设计上，ngx_lua 使用多个“轻量级线程”的模型。这些“轻量级线程”都是基于 Lua coroutine
的，再多的“轻线程”都是运行在一个 OS 线程里面的。

另外，值得一提的是，你在设计请求间的数据交换时，需要注意 nginx 的多 worker 进程的通信模型（除非你只配置单个 nginx
worker，但那样的话，你的 nginx 服务器就只能利用到一个逻辑 CPU 核）。你在 Lua VM 里的数据是不能直接跨越当前
worker 进程的边界的。类似地，系统级别的 epoll/poll/select
事件也是不能直接跨域进程边界的。你需要自己设计这里的数据交换和共享策略（比如基于 ngx_lua 提供的共享内存字典，或者基于 redis
这样的外部共享服务）。当然，如果你的前端有多个 nginx 实例，就更要注意这里的请求分发和数据共享问题。

Regards,
-agentzh

agentzh

Hello!

2014-02-23 5:44 GMT-08:00 小冶:
> 那么两个socket之间要互发数据，只能是先把数据写到外部共享如redis里，通过自己约好的某种协议规则，每个request在while循环的每一帧里去检查获取，然后给自己的socket下发。
> 这样一来，就还是需要一个更高效的类epoll机制，即可以同时等待多种事件，比如自己socket有数据到达，或是外部存储有新数据填充，或者是共享内存里有新数据。

一般有两种思路：

1. 使用 ngx.shared.DICT + ngx.sleep
自己按时轮询，可以使用变化步长（比如在开始时使用较短步长，然后逐渐提高步长）。优点是效率较高，毕竟 ngx.sleep
是非阻塞的，代价很小；缺点是实时性稍差一些，最多会引入一个步长的额外延时。

2. 使用 redis 自己的 long poll 接口，比如 pub/sub API 和 blpop. 优点是不用自己通过 sleep
引入不必要的额外的等待；缺点是增加了 socket 本身的开销。

Regards,
-agentzh

fatfatson

其实socket.recv本身就是挂起等待的，不需要sleep了啊。所谓步长也就是recv的超时时间。

用redis的blpop，那就相当于把挂起移到了redis这边，步长就是blpop的超时时间。

以上两种做法，都是带超时地死等一个，然后无阻塞查询另一个，所以必然是无阻塞查询的那一个会有延迟，因为延在死等的那一个上了。

所以我真正要想的是，能同时等待两个事件的原语api，任何一个有消息都能马上返回，处理完后又开始同时等待。

类似windows的WaitMultiObject吧，可以同时挂在 socket\窗口消息\信号灯等等各种对像上等待的。

在 2014年2月25日星期二UTC+8上午8时37分36秒，agentzh写道：

Hello!

2014-02-23 5:44 GMT-08:00 小冶:
> 那么两个socket之间要互发数据，只能是先把数据写到外部共享如redis里，通过自己约好的某种协议规则，每个request在while循环的每一帧里去检查获取，然后给自己的socket下发。
> 这样一来，就还是需要一个更高效的类epoll机制，即可以同时等待多种事件，比如自己socket有数据到达，或是外部存储有新数据填充，或者是共享内存里有新数据。

一般有两种思路：

1. 使用 ngx.shared.DICT + ngx.sleep
自己按时轮询，可以使用变化步长（比如在开始时使用较短步长，然后逐渐提高步长）。优点是效率较高，毕竟 ngx.sleep
是非阻塞的，代价很小；缺点是实时性稍差一些，最多会引入一个步长的额外延时。

2. 使用 redis 自己的 long poll 接口，比如 pub/sub API 和 blpop. 优点是不用自己通过 sleep
引入不必要的额外的等待；缺点是增加了 socket 本身的开销。

Regards,
-agentzh

agentzh

Hello!

2014-02-24 18:50 GMT-08:00 小冶:
> 其实socket.recv本身就是挂起等待的，不需要sleep了啊。

你重新仔细看我上一封邮件。我说的是两种平行的思路，并没有让你同时在一个地方使用它们。

> 所谓步长也就是recv的超时时间。

把 recv 超时当步长用不是推荐的做法。

> 用redis的blpop，那就相当于把挂起移到了redis这边，步长就是blpop的超时时间。

我的本意并不是让你的 blpop 操作超时轮询。blpop 会在有新数据时立即返回，所以尽量使用尽可能长的超时。建议仔细阅读 redis
的官方命令手册，以节约时间。

> 以上两种做法，都是带超时地死等一个，然后无阻塞查询另一个，所以必然是无阻塞查询的那一个会有延迟，因为延在死等的那一个上了。

Lua 级别上的那两种等都是开销很小的等，并不会阻塞任何 OS 线程。

> 所以我真正要想的是，能同时等待两个事件的原语api，任何一个有消息都能马上返回，处理完后又开始同时等待。
> 类似windows的WaitMultiObject吧，可以同时挂在 socket\窗口消息\信号灯等等各种对像上等待的。
>

我提供的两种思路在系统调用层面上都是等在 NGINX 事件循环体里的 epoll_wait 系统调用上面，我没看出来和 Windows 的
WaitForMultipleObjects 函数有什么本质上的区别。

Regards,
-agentzh

fatfatson

还是没搞明白啊，春哥再帮忙看看：

现在我的代码结构是：

while true do

net_msg = wsocket:recv_frame()

if net_msg then

send_msg_to_redis(net_msg)

end

redis_msg = read_from_redis()

if redis_msg then

wsocket:send_text(redis_msg)

end

我理解是：每个ws请求，就会生成一个coroutine来跑上面这段代码，但多个coroutine可能跑在不同的进程里，所以互相之间只好通过redis来中转消息。

现在，我把websocket超时设为5秒，所以如果第3秒时其它人已经发了新的信息并转到redis里了，我也要5秒后才能去取，延迟了2秒。

怎么才能同时监听websocket和redis过来的消息呢？做到不管谁有消息来，都能马上响应，转发给另一个。

在 2014年2月25日星期二UTC+8上午11时31分17秒，agentzh写道：

Hello!

2014-02-24 18:50 GMT-08:00 小冶:
> 其实socket.recv本身就是挂起等待的，不需要sleep了啊。

你重新仔细看我上一封邮件。我说的是两种平行的思路，并没有让你同时在一个地方使用它们。

> 所谓步长也就是recv的超时时间。

把 recv 超时当步长用不是推荐的做法。

> 用redis的blpop，那就相当于把挂起移到了redis这边，步长就是blpop的超时时间。

我的本意并不是让你的 blpop 操作超时轮询。blpop 会在有新数据时立即返回，所以尽量使用尽可能长的超时。建议仔细阅读 redis
的官方命令手册，以节约时间。

> 以上两种做法，都是带超时地死等一个，然后无阻塞查询另一个，所以必然是无阻塞查询的那一个会有延迟，因为延在死等的那一个上了。

Lua 级别上的那两种等都是开销很小的等，并不会阻塞任何 OS 线程。

> 所以我真正要想的是，能同时等待两个事件的原语api，任何一个有消息都能马上返回，处理完后又开始同时等待。
> 类似windows的WaitMultiObject吧，可以同时挂在 socket\窗口消息\信号灯等等各种对像上等待的。
>

我提供的两种思路在系统调用层面上都是等在 NGINX 事件循环体里的 epoll_wait 系统调用上面，我没看出来和 Windows 的
WaitForMultipleObjects 函数有什么本质上的区别。

Regards,
-agentzh

doujiang24

local ws = websocket:new()

local push = function ()

local ws = ws

while true do

local msg = read_from_redis()

if msg then

ws:send(msg)

end

local co = ngx.thread.spwan(push)

while true do

local msg = ws:recv()

if msg then

send_to_redis(msg)

end

ngx.thread.wait(co)

新开启一个 thread 负责从 redis 读取并推送到 ws 下游，当前 thread 读取 ws 推送到 reids

两个 thread 能并发执行，消息能即时传递

现在的问题在于 ws 不能在在两个 thread 里并发读写，等春哥合并了全双工就可以了

在 2014年2月26日上午11:13，小冶 <fatf...@gmail.com>写道：

还是没搞明白啊，春哥再帮忙看看：
现在我的代码结构是：
while true do
net_msg = wsocket:recv_frame()
if net_msg then
send_msg_to_redis(net_msg)
end

redis_msg = read_from_redis()
if redis_msg then
wsocket:send_text(redis_msg)
end
end

我理解是：每个ws请求，就会生成一个coroutine来跑上面这段代码，但多个coroutine可能跑在不同的进程里，所以互相之间只好通过redis来中转消息。

现在，我把websocket超时设为5秒，所以如果第3秒时其它人已经发了新的信息并转到redis里了，我也要5秒后才能去取，延迟了2秒。
怎么才能同时监听websocket和redis过来的消息呢？做到不管谁有消息来，都能马上响应，转发给另一个。

在 2014年2月25日星期二UTC+8上午11时31分17秒，agentzh写道：
Hello!

2014-02-24 18:50 GMT-08:00 小冶:
> 其实socket.recv本身就是挂起等待的，不需要sleep了啊。

你重新仔细看我上一封邮件。我说的是两种平行的思路，并没有让你同时在一个地方使用它们。

> 所谓步长也就是recv的超时时间。

把 recv 超时当步长用不是推荐的做法。

> 用redis的blpop，那就相当于把挂起移到了redis这边，步长就是blpop的超时时间。

我的本意并不是让你的 blpop 操作超时轮询。blpop 会在有新数据时立即返回，所以尽量使用尽可能长的超时。建议仔细阅读 redis
的官方命令手册，以节约时间。

> 以上两种做法，都是带超时地死等一个，然后无阻塞查询另一个，所以必然是无阻塞查询的那一个会有延迟，因为延在死等的那一个上了。

Lua 级别上的那两种等都是开销很小的等，并不会阻塞任何 OS 线程。

> 所以我真正要想的是，能同时等待两个事件的原语api，任何一个有消息都能马上返回，处理完后又开始同时等待。
> 类似windows的WaitMultiObject吧，可以同时挂在 socket\窗口消息\信号灯等等各种对像上等待的。
>

我提供的两种思路在系统调用层面上都是等在 NGINX 事件循环体里的 epoll_wait 系统调用上面，我没看出来和 Windows 的
WaitForMultipleObjects 函数有什么本质上的区别。

Regards,
-agentzh

--

fatfatson

原来还有这种用法啊！高，实在是高！

那现在就只等全双工补丁了

在 2014年2月26日星期三UTC+8下午3时41分24秒，doujiang写道：

local ws = websocket:new()

local push = function ()
local ws = ws

while true do
local msg = read_from_redis()

if msg then
ws:send(msg)
end
end

local co = ngx.thread.spwan(push)

while true do
local msg = ws:recv()

if msg then
send_to_redis(msg)

end
end

ngx.thread.wait(co)

新开启一个 thread 负责从 redis 读取并推送到 ws 下游，当前 thread 读取 ws 推送到 reids

两个 thread 能并发执行，消息能即时传递

现在的问题在于 ws 不能在在两个 thread 里并发读写，等春哥合并了全双工就可以了

在 2014年2月26日上午11:13，小冶 <fatf...@gmail.com>写道：

还是没搞明白啊，春哥再帮忙看看：
现在我的代码结构是：
while true do
net_msg = wsocket:recv_frame()
if net_msg then
send_msg_to_redis(net_msg)
end

redis_msg = read_from_redis()
if redis_msg then
wsocket:send_text(redis_msg)
end
end

我理解是：每个ws请求，就会生成一个coroutine来跑上面这段代码，但多个coroutine可能跑在不同的进程里，所以互相之间只好通过redis来中转消息。

现在，我把websocket超时设为5秒，所以如果第3秒时其它人已经发了新的信息并转到redis里了，我也要5秒后才能去取，延迟了2秒。
怎么才能同时监听websocket和redis过来的消息呢？做到不管谁有消息来，都能马上响应，转发给另一个。

在 2014年2月25日星期二UTC+8上午11时31分17秒，agentzh写道：
Hello!

2014-02-24 18:50 GMT-08:00 小冶:
> 其实socket.recv本身就是挂起等待的，不需要sleep了啊。

你重新仔细看我上一封邮件。我说的是两种平行的思路，并没有让你同时在一个地方使用它们。

> 所谓步长也就是recv的超时时间。

把 recv 超时当步长用不是推荐的做法。

> 用redis的blpop，那就相当于把挂起移到了redis这边，步长就是blpop的超时时间。

我的本意并不是让你的 blpop 操作超时轮询。blpop 会在有新数据时立即返回，所以尽量使用尽可能长的超时。建议仔细阅读 redis
的官方命令手册，以节约时间。

> 以上两种做法，都是带超时地死等一个，然后无阻塞查询另一个，所以必然是无阻塞查询的那一个会有延迟，因为延在死等的那一个上了。

Lua 级别上的那两种等都是开销很小的等，并不会阻塞任何 OS 线程。

> 所以我真正要想的是，能同时等待两个事件的原语api，任何一个有消息都能马上返回，处理完后又开始同时等待。
> 类似windows的WaitMultiObject吧，可以同时挂在 socket\窗口消息\信号灯等等各种对像上等待的。
>

我提供的两种思路在系统调用层面上都是等在 NGINX 事件循环体里的 epoll_wait 系统调用上面，我没看出来和 Windows 的
WaitForMultipleObjects 函数有什么本质上的区别。

Regards,
-agentzh

--

kytexzy

On Wednesday, February 26, 2014 3:41:24 PM UTC+8, doujiang wrote:

local ws = websocket:new()

local push = function ()
local ws = ws

while true do
local msg = read_from_redis()

if msg then
ws:send(msg)
end
end

local co = ngx.thread.spwan(push)

while true do
local msg = ws:recv()

if msg then
send_to_redis(msg)

end
end

ngx.thread.wait(co)

新开启一个 thread 负责从 redis 读取并推送到 ws 下游，当前 thread 读取 ws 推送到 reids

两个 thread 能并发执行，消息能即时传递

现在的问题在于 ws 不能在在两个 thread 里并发读写，等春哥合并了全双工就可以了

主线程负责拉，新开的线程负责推.
不知道ngx.thread.wait(co)这句话不用有木有什么不妥的地方？
我在我的实现中就直接用了一个ngx.thread.spawn没有用ngx.thread.wait，感觉也没有什么问题。

agentzh

Hello!

2014-02-26 3:39 GMT-08:00 Nero.Ping:
> 主线程负责拉，新开的线程负责推.

对，通过多个轻线程把读写分离开是推荐的玩法。

我会尽快审核并融合那个 cosocket 读写分离的补丁。这个确实很重要 :)

> 不知道ngx.thread.wait(co)这句话不用有木有什么不妥的地方？
> 我在我的实现中就直接用了一个ngx.thread.spawn没有用ngx.thread.wait，感觉也没有什么问题。
>

当不使用 ngx.thread.wait() 时，父线程并不会等子线程而提前退出。但整个请求的 handler 会等所有线程都结束后才结束，所以也不会有问题。

Regards,
-agentzh