目前Ngx_lua是否不支持控制其他request协程？

spirittf · 2013-12-11T12:10:08+00:00

Hello! 2013/12/10 Keqiang Ye: > > 最后这个编码后的url，请求nginx的时&#x5...

目前Ngx_lua是否不支持控制其他request协程？

spirittf

看GitHub上的文档，ngx_lua是one-coroutine-per-request isolation design。

但我这边想做一个类似push的项目，希望能够resume其他用户请求协程，同时传值过去。

我不是特别清楚当前版本的Ngx_lua是否可以做到。

或者，我想，用ngx.req.tcp()取得用户请求的cosocket，放到全局的table里(lua_code_cache开启的情况下利用module存储)，当发消息的请求过来的时候，可以从这个全局table找到对应的cosocket来下发消息。可惜看了下文档，这个ngx.req.tcp()返回的cosocket是只读的。

另外，如果在当前request里面coroutine.yield()，还是返回一个标准的http response给client了，那我如何挂起用户的请求呢，难道只能ngx.sleep吗？

非常感谢！

agentzh

Hello!

2013/12/10 田峰:
> 看GitHub上的文档，ngx_lua是one-coroutine-per-request isolation design。
> 但我这边想做一个类似push的项目，希望能够resume其他用户请求协程，同时传值过去。
> 我不是特别清楚当前版本的Ngx_lua是否可以做到。

ngx_lua 中的协程对象的生命期都是与当前请求绑定的。不能跨越请求的边界传递协程对象。

这种跨请求操纵协程（或“轻线程”）的用法在 nginx 的进程模型下没有太大的实用价值，毕竟一般都会配置多个 nginx worker
进程（以便能利到到多个 CPU 核），而 Lua VM 是不可能跨越进程空间在所有 worker 进程之间共享的。

推荐使用 ngx.sleep() + 共享内存字典。比如 lua-resty-lock 库就是这么实现不会阻塞 nginx worker 进程的全局锁的：

    https://github.com/agentzh/lua-resty-lock

另一种做法就是使用外部的数据发布和订阅服务，比如 redis 的 blpop 命令。这种玩法的实时性一般会更好一些，但开销会大许多。

> 另外，如果在当前request里面coroutine.yield()，还是返回一个标准的http
> response给client了，那我如何挂起用户的请求呢，难道只能ngx.sleep吗？

在当前请求的“主线程”的上下文中调用 coroutine.yield()
会挂起“主线程”，但并不会无限挂起。当当前请求的协程调度器中没有其他等待执行的“轻线程”时，被挂起的“主线程”会立即
resume，继续运行。

Regards,
-agentzh

spirittf

Thanks for ur reply!

于私而言，建议加入跨请求操纵协程的facility :-)

虽然Nginx在多cpu的生产环境中一般都会开启多个worker进程，针对push的场景，我们可以用外部存储或者就简单实用Nginx_Lua提供的shared dict来记录一个订阅者uid对应协程id及当前worker_process_id的map。

发布消息给特定订阅者的request被任意worker进程接受后，可以从第一个map中查找到对应的woker_process_id及协程id：是本worker，很简单，直接找到相应协程resume之(并传入参数)；如果不是本worker，需要Nginx_Lua再封装一组通过socketpair和其他woker通信的Nginx API -__-

Sorry，我自己也感觉有点过分了，但如果支持跨请求操纵协程，我们把worker process数量配为1，起n个Nginx听不同的端口，跨进程问题可以利用http通信解决。

Ok，可能我的这些诉求不太match Nginx_Lua所定位的应用场景，我还是尊重作者的意愿的。

其实我的目的就是打造一个灵活轻巧高性能的push系统，如果不能利用Nginx_Lua，我考虑给lua写一个CLib来让lua可以使用epoll，然后直接用lua来构建一个push系统(参考你对Nginx_Lua的实现：一个连接一个协程)。

Regards,
-Frank

在 2013年12月12日星期四UTC+8上午3时51分15秒，agentzh写道：

Hello!

2013/12/10 田峰:
> 看GitHub上的文档，ngx_lua是one-coroutine-per-request isolation design。
> 但我这边想做一个类似push的项目，希望能够resume其他用户请求协程，同时传值过去。
> 我不是特别清楚当前版本的Ngx_lua是否可以做到。

ngx_lua 中的协程对象的生命期都是与当前请求绑定的。不能跨越请求的边界传递协程对象。

这种跨请求操纵协程（或“轻线程”）的用法在 nginx 的进程模型下没有太大的实用价值，毕竟一般都会配置多个 nginx worker
进程（以便能利到到多个 CPU 核），而 Lua VM 是不可能跨越进程空间在所有 worker 进程之间共享的。

推荐使用 ngx.sleep() + 共享内存字典。比如 lua-resty-lock 库就是这么实现不会阻塞 nginx worker 进程的全局锁的：

https://github.com/agentzh/lua-resty-lock

另一种做法就是使用外部的数据发布和订阅服务，比如 redis 的 blpop 命令。这种玩法的实时性一般会更好一些，但开销会大许多。

> 另外，如果在当前request里面coroutine.yield()，还是返回一个标准的http
> response给client了，那我如何挂起用户的请求呢，难道只能ngx.sleep吗？

在当前请求的“主线程”的上下文中调用 coroutine.yield()
会挂起“主线程”，但并不会无限挂起。当当前请求的协程调度器中没有其他等待执行的“轻线程”时，被挂起的“主线程”会立即
resume，继续运行。

Regards,
-agentzh

spirittf

To agnetzh:

另一种做法就是使用外部的数据发布和订阅服务，比如 redis 的 blpop 命令。这种玩法的实时性一般会更好一些，但开销会大许多。

—— 利用redis的bpop来做push的确是我目前的方案，为了规避连接数*2，我们把redis和nginx放在一台机器上，使用unix domain socket来通信。

显然，这种肯定不是一种完美的方案。

Regards,

-Frank

在 2013年12月12日星期四UTC+8下午6时14分02秒，田峰写道：

Thanks for ur reply!

于私而言，建议加入跨请求操纵协程的facility :-)

虽然Nginx在多cpu的生产环境中一般都会开启多个worker进程，针对push的场景，我们可以用外部存储或者就简单实用Nginx_Lua提供的shared dict来记录一个订阅者uid对应协程id及当前worker_process_id的map。

发布消息给特定订阅者的request被任意worker进程接受后，可以从第一个map中查找到对应的woker_process_id及协程id：是本worker，很简单，直接找到相应协程resume之(并传入参数)；如果不是本worker，需要Nginx_Lua再封装一组通过socketpair和其他woker通信的Nginx API -__-

Sorry，我自己也感觉有点过分了，但如果支持跨请求操纵协程，我们把worker process数量配为1，起n个Nginx听不同的端口，跨进程问题可以利用http通信解决。

Ok，可能我的这些诉求不太match Nginx_Lua所定位的应用场景，我还是尊重作者的意愿的。

其实我的目的就是打造一个灵活轻巧高性能的push系统，如果不能利用Nginx_Lua，我考虑给lua写一个CLib来让lua可以使用epoll，然后直接用lua来构建一个push系统(参考你对Nginx_Lua的实现：一个连接一个协程)。

Regards,
-Frank

在 2013年12月12日星期四UTC+8上午3时51分15秒，agentzh写道：
Hello!

2013/12/10 田峰:
> 看GitHub上的文档，ngx_lua是one-coroutine-per-request isolation design。
> 但我这边想做一个类似push的项目，希望能够resume其他用户请求协程，同时传值过去。
> 我不是特别清楚当前版本的Ngx_lua是否可以做到。

ngx_lua 中的协程对象的生命期都是与当前请求绑定的。不能跨越请求的边界传递协程对象。

这种跨请求操纵协程（或“轻线程”）的用法在 nginx 的进程模型下没有太大的实用价值，毕竟一般都会配置多个 nginx worker
进程（以便能利到到多个 CPU 核），而 Lua VM 是不可能跨越进程空间在所有 worker 进程之间共享的。

推荐使用 ngx.sleep() + 共享内存字典。比如 lua-resty-lock 库就是这么实现不会阻塞 nginx worker 进程的全局锁的：

https://github.com/agentzh/lua-resty-lock

另一种做法就是使用外部的数据发布和订阅服务，比如 redis 的 blpop 命令。这种玩法的实时性一般会更好一些，但开销会大许多。

> 另外，如果在当前request里面coroutine.yield()，还是返回一个标准的http
> response给client了，那我如何挂起用户的请求呢，难道只能ngx.sleep吗？

在当前请求的“主线程”的上下文中调用 coroutine.yield()
会挂起“主线程”，但并不会无限挂起。当当前请求的协程调度器中没有其他等待执行的“轻线程”时，被挂起的“主线程”会立即
resume，继续运行。

Regards,
-agentzh

agentzh

Hello!

2013/12/12 田峰:
> 于私而言，建议加入跨请求操纵协程的facility :-)
>

呵呵，好吧，我乐意给 ngx_lua 添加这样的功能 :)

不过我不想让“轻线程”对应的 lua thread 对象直接暴露给其他请求，因为 lua thread
对象本身并没有携带其所属请求的信息，所以如果要支持在其他请求中操纵它，则需要全局查找，开销可能会比较大（特别是在 C10K 的场景下）。

我有一个想法，或许我们可以提供一个更抽象一些的机制，比如类似 POSIX semaphore
的接口（http://www.csc.villanova.edu/~mdamian/threads/posixsem.html），提供;
semaphore 对象对于轻线程之间的同步。我们可以允许 semaphore 对象在当前的 Lua VM 级别上共享（在
lua_code_cache off 时也就是 nginx worker 进程级别的共享）。

这样“订阅者”轻线程可以等待在 ngx.thread.sem_wait() 上，而“发布者”轻线程可以调用
ngx.thread.sem_post() 唤醒等待在当前 semaphore 上的轻线程。

这种设计有如下好处：

1. 我们可以在 sem_wait() 调用里面把当前请求的相关状态信息保存在我们的 semaphore 对象中，避免全局请求状态的查找。

2. 可以把轻线程同步 API 与标准 Lua 的 coroutine API 清楚地隔离开，毕竟它们的语义已经相去甚远。

3. 同时，我们也可以很方便地在 sem_wait() 中添加超时设置等保护。

4. 当被挂起的轻线程被杀或者对应的请求提前终止时，我们也方便执行相应的清理工作，避免状态的不一致。

> 虽然Nginx在多cpu的生产环境中一般都会开启多个worker进程，针对push的场景，我们可以用外部存储或者就简单实用Nginx_Lua提供的shared
> dict来记录一个订阅者uid对应协程id及当前worker_process_id的map。
>

这里我们改成记录 semaphore 对象的 id 就好了。

另外，这里我们不要记录当前 nginx worker 进程的 pid，因为 worker
进程有可能意外退出（比如崩溃），虽然这不是正常情况，但需要对这种极端情况进行保护。各个 nginx worker 可以用它监听的端口或者
socket 文件路径来标识。

> 发布消息给特定订阅者的request被任意worker进程接受后，可以从第一个map中查找到对应的woker_process_id及协程id：是本worker，很简单，直接找到相应协程resume之(并传入参数)；

这里可以改成，直接在 semaphore 对象上面调用 sem_post()
唤醒正等待在此对象上面的所有“轻线程”。这样“发布者”轻线程不用直接操纵其他请求里面的“订阅者”轻线程。

> 如果不是本worker，需要Nginx_Lua再封装一组通过socketpair和其他woker通信的Nginx
> API -__-
>

我们可以给 ngx_lua 现有的 cosocket API 添加监听 socket 的支持。我们或许可以从 unix domain
socket 开始。然后，我们需要一个 init_worker_by_lua 配置指令，这样我们可以在 worker 启动时执行我们指定的
Lua 代码（戴冠兰已经基本实现了这个功能，我会在近期融合补丁）。

有了这些，nginx worker 间的 socket 通信可以这么搞：

1. 在 init_worker_by_lua 里面创建一个新的监听 socket 对象，并把当前对象对应的文件路径（或端口号）注册到
ngx_lua 共享内存字典中,这样其他 worker 可以看到。

2. 然后在 init_worker_by_lua 里通过现有的 ngx.timer.at() 接口创建一个 0 延时的 timer，在
timer 回调里通过一个 Lua 循环不断通过 accept() 接收新连接。

3. 对于每一个新连接通过 ngx.thread.spawn() 创建一个轻线程，在每个这样的轻线程里通过一个 Lua
循环不断接收该连接上的请求包，直到连接断开，或者当前 worker 开始退出（通过 ngx.worker.exiting() 检查）。

4. 我们可以根据接收到的请求包，决定对某个 semaphore 对象的操作，唤醒相应的请求里的轻线程。

这样一来我们只需要实现最基本的原语，其他通讯和调度逻辑都可以完全在 Lua 代码里面搞了，方便而灵活。你觉得如何？

> Sorry，我自己也感觉有点过分了，但如果支持跨请求操纵协程，我们把worker
> process数量配为1，起n个Nginx听不同的端口，跨进程问题可以利用http通信解决。
>

这种搞法比较纠结，运维层面复杂不少，虽然可以工作 :)

> Ok，可能我的这些诉求不太match Nginx_Lua所定位的应用场景，我还是尊重作者的意愿的。
>

ngx_lua 定位的应用场景是 web 应用。所以只要在 web 应用的范畴内，就都好商量，呵呵。而我的意愿一般是由用户社区和我自己的公司需求决定的 ;)

我上面提出的 ngx.thread semaphore、init_worker_by_lua、listening cosocket
都是有用的东西，很值得添加进 ngx_lua 核心中来 :)

> 其实我的目的就是打造一个灵活轻巧高性能的push系统，如果不能利用Nginx_Lua，我考虑给lua写一个CLib来让lua可以使用epoll，然后直接用lua来构建一个push系统(参考你对Nginx_Lua的实现：一个连接一个协程)。
>

你的目的对我来说也是很诱人的。我也非常欢迎你能加入到 ngx_lua 模块的设计和开发工作中来 :) 我显然更希望你能给 ngx_lua
贡献补丁，而不是另起炉灶 ;) 多谢！

Regards,
-agentzh

spirittf

Hello!

仔细看完了你的实现思路，只想用英式的中文说一句：不能同意更多！哈哈，真的很期待！

目前我会花一些业余精力给Luasocket贡献一组支持epoll的方法，以后有时间会考虑给ngx_lua做贡献:-)，人人为我，我为人人嘛

Regards,
-Frank

在 2013年12月13日星期五UTC+8上午2时41分27秒，agentzh写道：

Hello!

2013/12/12 田峰:
> 于私而言，建议加入跨请求操纵协程的facility :-)
>

呵呵，好吧，我乐意给 ngx_lua 添加这样的功能 :)

不过我不想让“轻线程”对应的 lua thread 对象直接暴露给其他请求，因为 lua thread
对象本身并没有携带其所属请求的信息，所以如果要支持在其他请求中操纵它，则需要全局查找，开销可能会比较大（特别是在 C10K 的场景下）。

我有一个想法，或许我们可以提供一个更抽象一些的机制，比如类似 POSIX semaphore
的接口（http://www.csc.villanova.edu/~mdamian/threads/posixsem.html），提供
semaphore 对象对于轻线程之间的同步。我们可以允许 semaphore 对象在当前的 Lua VM 级别上共享（在
lua_code_cache off 时也就是 nginx worker 进程级别的共享）。

这样“订阅者”轻线程可以等待在 ngx.thread.sem_wait() 上，而“发布者”轻线程可以调用
ngx.thread.sem_post() 唤醒等待在当前 semaphore 上的轻线程。

这种设计有如下好处：

1. 我们可以在 sem_wait() 调用里面把当前请求的相关状态信息保存在我们的 semaphore 对象中，避免全局请求状态的查找。

2. 可以把轻线程同步 API 与标准 Lua 的 coroutine API 清楚地隔离开，毕竟它们的语义已经相去甚远。

3. 同时，我们也可以很方便地在 sem_wait() 中添加超时设置等保护。

4. 当被挂起的轻线程被杀或者对应的请求提前终止时，我们也方便执行相应的清理工作，避免状态的不一致。

> 虽然Nginx在多cpu的生产环境中一般都会开启多个worker进程，针对push的场景，我们可以用外部存储或者就简单实用Nginx_Lua提供的shared
> dict来记录一个订阅者uid对应协程id及当前worker_process_id的map。
>

这里我们改成记录 semaphore 对象的 id 就好了。

另外，这里我们不要记录当前 nginx worker 进程的 pid，因为 worker
进程有可能意外退出（比如崩溃），虽然这不是正常情况，但需要对这种极端情况进行保护。各个 nginx worker 可以用它监听的端口或者
socket 文件路径来标识。

> 发布消息给特定订阅者的request被任意worker进程接受后，可以从第一个map中查找到对应的woker_process_id及协程id：是本worker，很简单，直接找到相应协程resume之(并传入参数)；

这里可以改成，直接在 semaphore 对象上面调用 sem_post()
唤醒正等待在此对象上面的所有“轻线程”。这样“发布者”轻线程不用直接操纵其他请求里面的“订阅者”轻线程。

> 如果不是本worker，需要Nginx_Lua再封装一组通过socketpair和其他woker通信的Nginx
> API -__-
>

我们可以给 ngx_lua 现有的 cosocket API 添加监听 socket 的支持。我们或许可以从 unix domain
socket 开始。然后，我们需要一个 init_worker_by_lua 配置指令，这样我们可以在 worker 启动时执行我们指定的
Lua 代码（戴冠兰已经基本实现了这个功能，我会在近期融合补丁）。

有了这些，nginx worker 间的 socket 通信可以这么搞：

1. 在 init_worker_by_lua 里面创建一个新的监听 socket 对象，并把当前对象对应的文件路径（或端口号）注册到
ngx_lua 共享内存字典中,这样其他 worker 可以看到。

2. 然后在 init_worker_by_lua 里通过现有的 ngx.timer.at() 接口创建一个 0 延时的 timer，在
timer 回调里通过一个 Lua 循环不断通过 accept() 接收新连接。

3. 对于每一个新连接通过 ngx.thread.spawn() 创建一个轻线程，在每个这样的轻线程里通过一个 Lua
循环不断接收该连接上的请求包，直到连接断开，或者当前 worker 开始退出（通过 ngx.worker.exiting() 检查）。

4. 我们可以根据接收到的请求包，决定对某个 semaphore 对象的操作，唤醒相应的请求里的轻线程。

这样一来我们只需要实现最基本的原语，其他通讯和调度逻辑都可以完全在 Lua 代码里面搞了，方便而灵活。你觉得如何？

> Sorry，我自己也感觉有点过分了，但如果支持跨请求操纵协程，我们把worker
> process数量配为1，起n个Nginx听不同的端口，跨进程问题可以利用http通信解决。
>

这种搞法比较纠结，运维层面复杂不少，虽然可以工作 :)

> Ok，可能我的这些诉求不太match Nginx_Lua所定位的应用场景，我还是尊重作者的意愿的。
>

ngx_lua 定位的应用场景是 web 应用。所以只要在 web 应用的范畴内，就都好商量，呵呵。而我的意愿一般是由用户社区和我自己的公司需求决定的 ;)

我上面提出的 ngx.thread semaphore、init_worker_by_lua、listening cosocket
都是有用的东西，很值得添加进 ngx_lua 核心中来 :)

> 其实我的目的就是打造一个灵活轻巧高性能的push系统，如果不能利用Nginx_Lua，我考虑给lua写一个CLib来让lua可以使用epoll，然后直接用lua来构建一个push系统(参考你对Nginx_Lua的实现：一个连接一个协程)。
>

你的目的对我来说也是很诱人的。我也非常欢迎你能加入到 ngx_lua 模块的设计和开发工作中来 :) 我显然更希望你能给 ngx_lua
贡献补丁，而不是另起炉灶 ;) 多谢！

Regards,
-agentzh

sushq09

我也遇到了push的场景，如章哥说的，使用semaphore做到每个客户端websocket长连接注册semaphore，并在循环中等待被唤醒，

使用init_worker_by_lua在worker启动的时候用timmer 0.001定时检查sharedDict的变化，处理消息的接口把数据插入到sharedDict中，

定时检查sharedDict变化的效率很低。

刚看到这个listening cosocket，不知道是否已经实现的这个功能？要怎么使用这个功能

在 2013年12月13日星期五 UTC+8上午2:41:27，agentzh写道：

Hello!

2013/12/12 田峰:
> 于私而言，建议加入跨请求操纵协程的facility :-)
>

呵呵，好吧，我乐意给 ngx_lua 添加这样的功能 :)

不过我不想让“轻线程”对应的 lua thread 对象直接暴露给其他请求，因为 lua thread
对象本身并没有携带其所属请求的信息，所以如果要支持在其他请求中操纵它，则需要全局查找，开销可能会比较大（特别是在 C10K 的场景下）。

我有一个想法，或许我们可以提供一个更抽象一些的机制，比如类似 POSIX semaphore
的接口（http://www.csc.villanova.edu/~mdamian/threads/posixsem.html），提供
semaphore 对象对于轻线程之间的同步。我们可以允许 semaphore 对象在当前的 Lua VM 级别上共享（在
lua_code_cache off 时也就是 nginx worker 进程级别的共享）。

这样“订阅者”轻线程可以等待在 ngx.thread.sem_wait() 上，而“发布者”轻线程可以调用
ngx.thread.sem_post() 唤醒等待在当前 semaphore 上的轻线程。

这种设计有如下好处：

1. 我们可以在 sem_wait() 调用里面把当前请求的相关状态信息保存在我们的 semaphore 对象中，避免全局请求状态的查找。

2. 可以把轻线程同步 API 与标准 Lua 的 coroutine API 清楚地隔离开，毕竟它们的语义已经相去甚远。

3. 同时，我们也可以很方便地在 sem_wait() 中添加超时设置等保护。

4. 当被挂起的轻线程被杀或者对应的请求提前终止时，我们也方便执行相应的清理工作，避免状态的不一致。

> 虽然Nginx在多cpu的生产环境中一般都会开启多个worker进程，针对push的场景，我们可以用外部存储或者就简单实用Nginx_Lua提供的shared
> dict来记录一个订阅者uid对应协程id及当前worker_process_id的map。
>

这里我们改成记录 semaphore 对象的 id 就好了。

另外，这里我们不要记录当前 nginx worker 进程的 pid，因为 worker
进程有可能意外退出（比如崩溃），虽然这不是正常情况，但需要对这种极端情况进行保护。各个 nginx worker 可以用它监听的端口或者
socket 文件路径来标识。

> 发布消息给特定订阅者的request被任意worker进程接受后，可以从第一个map中查找到对应的woker_process_id及协程id：是本worker，很简单，直接找到相应协程resume之(并传入参数)；

这里可以改成，直接在 semaphore 对象上面调用 sem_post()
唤醒正等待在此对象上面的所有“轻线程”。这样“发布者”轻线程不用直接操纵其他请求里面的“订阅者”轻线程。

> 如果不是本worker，需要Nginx_Lua再封装一组通过socketpair和其他woker通信的Nginx
> API -__-
>

我们可以给 ngx_lua 现有的 cosocket API 添加监听 socket 的支持。我们或许可以从 unix domain
socket 开始。然后，我们需要一个 init_worker_by_lua 配置指令，这样我们可以在 worker 启动时执行我们指定的
Lua 代码（戴冠兰已经基本实现了这个功能，我会在近期融合补丁）。

有了这些，nginx worker 间的 socket 通信可以这么搞：

1. 在 init_worker_by_lua 里面创建一个新的监听 socket 对象，并把当前对象对应的文件路径（或端口号）注册到
ngx_lua 共享内存字典中,这样其他 worker 可以看到。

2. 然后在 init_worker_by_lua 里通过现有的 ngx.timer.at() 接口创建一个 0 延时的 timer，在
timer 回调里通过一个 Lua 循环不断通过 accept() 接收新连接。

3. 对于每一个新连接通过 ngx.thread.spawn() 创建一个轻线程，在每个这样的轻线程里通过一个 Lua
循环不断接收该连接上的请求包，直到连接断开，或者当前 worker 开始退出（通过 ngx.worker.exiting() 检查）。

4. 我们可以根据接收到的请求包，决定对某个 semaphore 对象的操作，唤醒相应的请求里的轻线程。

这样一来我们只需要实现最基本的原语，其他通讯和调度逻辑都可以完全在 Lua 代码里面搞了，方便而灵活。你觉得如何？

> Sorry，我自己也感觉有点过分了，但如果支持跨请求操纵协程，我们把worker
> process数量配为1，起n个Nginx听不同的端口，跨进程问题可以利用http通信解决。
>

这种搞法比较纠结，运维层面复杂不少，虽然可以工作 :)

> Ok，可能我的这些诉求不太match Nginx_Lua所定位的应用场景，我还是尊重作者的意愿的。
>

ngx_lua 定位的应用场景是 web 应用。所以只要在 web 应用的范畴内，就都好商量，呵呵。而我的意愿一般是由用户社区和我自己的公司需求决定的 ;)

我上面提出的 ngx.thread semaphore、init_worker_by_lua、listening cosocket
都是有用的东西，很值得添加进 ngx_lua 核心中来 :)

> 其实我的目的就是打造一个灵活轻巧高性能的push系统，如果不能利用Nginx_Lua，我考虑给lua写一个CLib来让lua可以使用epoll，然后直接用lua来构建一个push系统(参考你对Nginx_Lua的实现：一个连接一个协程)。
>

你的目的对我来说也是很诱人的。我也非常欢迎你能加入到 ngx_lua 模块的设计和开发工作中来 :) 我显然更希望你能给 ngx_lua
贡献补丁，而不是另起炉灶 ;) 多谢！

Regards,
-agentzh

doujiang24

ngx.semaphore 用于 worker 内的跨请求通讯，

sharedict 用于 worker 之间的通讯，这里搞个轮询，其实效率也不差，只是有一点固定延时

listening cosocket，还没有实现

shann su <sus...@gmail.com> 于2019年6月21日周五上午10:42写道：

我也遇到了push的场景，如章哥说的，使用semaphore做到每个客户端websocket长连接注册semaphore，并在循环中等待被唤醒，
使用init_worker_by_lua在worker启动的时候用timmer 0.001定时检查sharedDict的变化，处理消息的接口把数据插入到sharedDict中，
定时检查sharedDict变化的效率很低。
刚看到这个listening cosocket，不知道是否已经实现的这个功能？要怎么使用这个功能

在 2013年12月13日星期五 UTC+8上午2:41:27，agentzh写道：
Hello!

2013/12/12 田峰:
> 于私而言，建议加入跨请求操纵协程的facility :-)
>

呵呵，好吧，我乐意给 ngx_lua 添加这样的功能 :)

不过我不想让“轻线程”对应的 lua thread 对象直接暴露给其他请求，因为 lua thread
对象本身并没有携带其所属请求的信息，所以如果要支持在其他请求中操纵它，则需要全局查找，开销可能会比较大（特别是在 C10K 的场景下）。

我有一个想法，或许我们可以提供一个更抽象一些的机制，比如类似 POSIX semaphore
的接口（http://www.csc.villanova.edu/~mdamian/threads/posixsem.html），提供
semaphore 对象对于轻线程之间的同步。我们可以允许 semaphore 对象在当前的 Lua VM 级别上共享（在
lua_code_cache off 时也就是 nginx worker 进程级别的共享）。

这样“订阅者”轻线程可以等待在 ngx.thread.sem_wait() 上，而“发布者”轻线程可以调用
ngx.thread.sem_post() 唤醒等待在当前 semaphore 上的轻线程。

这种设计有如下好处：

1. 我们可以在 sem_wait() 调用里面把当前请求的相关状态信息保存在我们的 semaphore 对象中，避免全局请求状态的查找。

2. 可以把轻线程同步 API 与标准 Lua 的 coroutine API 清楚地隔离开，毕竟它们的语义已经相去甚远。

3. 同时，我们也可以很方便地在 sem_wait() 中添加超时设置等保护。

4. 当被挂起的轻线程被杀或者对应的请求提前终止时，我们也方便执行相应的清理工作，避免状态的不一致。

> 虽然Nginx在多cpu的生产环境中一般都会开启多个worker进程，针对push的场景，我们可以用外部存储或者就简单实用Nginx_Lua提供的shared
> dict来记录一个订阅者uid对应协程id及当前worker_process_id的map。
>

这里我们改成记录 semaphore 对象的 id 就好了。

另外，这里我们不要记录当前 nginx worker 进程的 pid，因为 worker
进程有可能意外退出（比如崩溃），虽然这不是正常情况，但需要对这种极端情况进行保护。各个 nginx worker 可以用它监听的端口或者
socket 文件路径来标识。

> 发布消息给特定订阅者的request被任意worker进程接受后，可以从第一个map中查找到对应的woker_process_id及协程id：是本worker，很简单，直接找到相应协程resume之(并传入参数)；

这里可以改成，直接在 semaphore 对象上面调用 sem_post()
唤醒正等待在此对象上面的所有“轻线程”。这样“发布者”轻线程不用直接操纵其他请求里面的“订阅者”轻线程。

> 如果不是本worker，需要Nginx_Lua再封装一组通过socketpair和其他woker通信的Nginx
> API -__-
>

我们可以给 ngx_lua 现有的 cosocket API 添加监听 socket 的支持。我们或许可以从 unix domain
socket 开始。然后，我们需要一个 init_worker_by_lua 配置指令，这样我们可以在 worker 启动时执行我们指定的
Lua 代码（戴冠兰已经基本实现了这个功能，我会在近期融合补丁）。

有了这些，nginx worker 间的 socket 通信可以这么搞：

1. 在 init_worker_by_lua 里面创建一个新的监听 socket 对象，并把当前对象对应的文件路径（或端口号）注册到
ngx_lua 共享内存字典中,这样其他 worker 可以看到。

2. 然后在 init_worker_by_lua 里通过现有的 ngx.timer.at() 接口创建一个 0 延时的 timer，在
timer 回调里通过一个 Lua 循环不断通过 accept() 接收新连接。

3. 对于每一个新连接通过 ngx.thread.spawn() 创建一个轻线程，在每个这样的轻线程里通过一个 Lua
循环不断接收该连接上的请求包，直到连接断开，或者当前 worker 开始退出（通过 ngx.worker.exiting() 检查）。

4. 我们可以根据接收到的请求包，决定对某个 semaphore 对象的操作，唤醒相应的请求里的轻线程。

这样一来我们只需要实现最基本的原语，其他通讯和调度逻辑都可以完全在 Lua 代码里面搞了，方便而灵活。你觉得如何？

> Sorry，我自己也感觉有点过分了，但如果支持跨请求操纵协程，我们把worker
> process数量配为1，起n个Nginx听不同的端口，跨进程问题可以利用http通信解决。
>

这种搞法比较纠结，运维层面复杂不少，虽然可以工作 :)

> Ok，可能我的这些诉求不太match Nginx_Lua所定位的应用场景，我还是尊重作者的意愿的。
>

ngx_lua 定位的应用场景是 web 应用。所以只要在 web 应用的范畴内，就都好商量，呵呵。而我的意愿一般是由用户社区和我自己的公司需求决定的 ;)

我上面提出的 ngx.thread semaphore、init_worker_by_lua、listening cosocket
都是有用的东西，很值得添加进 ngx_lua 核心中来 :)

> 其实我的目的就是打造一个灵活轻巧高性能的push系统，如果不能利用Nginx_Lua，我考虑给lua写一个CLib来让lua可以使用epoll，然后直接用lua来构建一个push系统(参考你对Nginx_Lua的实现：一个连接一个协程)。
>

你的目的对我来说也是很诱人的。我也非常欢迎你能加入到 ngx_lua 模块的设计和开发工作中来 :) 我显然更希望你能给 ngx_lua
贡献补丁，而不是另起炉灶 ;) 多谢！

Regards,
-agentzh