【(LUA相关)一个支持yield的server能避免掉轮询检查coroutine状态的命运吗?】

linux_c_py_php

starwing83 发表于 2013-02-24 18:47
回复 17# linux_c_py_php

现在服务的coroutine是针对连接的了， 我需要知道一个连接的coroutine是否结束， 因为只有结束了我才能回收这个coroutine并创建新的coroutine处理下一个请求.


两种办法:

1, 每个api在resume返回后(比如connect的event callback里做resume来触发lua代码继续往下执行), 判断结果并告知框架是否可以回收.
2, 框架轮询查看所有正在执行lua的coroutine是否已经dead并回收.

这种事情必须要做吧, GUI里什么时候回收coroutine, 总得有个时候, 我想知道是什么时候回收的.

starwing83

回复 20# linux_c_py_php


    ??????


你平时怎么处理回调的？回调如果执行过了，但是保留了一份状态，你需要知道这份状态需不需要继续保持么？你不需要对不对？（特别是针对有垃圾回收的语言）

你直接可以认为coroutine就是一系列可以连续回调的东西，回调的时候不需要知道这个回调的状态“有没有执行完”。

其实你还是没有一个完整设计coroutine的观念，而且就这么讨论我根本不可能知道你到底是哪儿理解错了。我建议这样：

你提一个你觉得需要轮询的场景，给出详细需求，我实现一份代码给你看。

你需要负责提供Lua层面的使用方法（Demo脚本），我负责提供能被require的库，当然所有网络请求我会做成在控制台输入文字控制的形式。（在控制台阻塞，你输入不同的命令模拟不同的情况，比如A请求已到，或者B请求出错等等）

linux_c_py_php

starwing83 发表于 2013-02-24 18:59
回复 20# linux_c_py_php

不是啊, lua从头执行到尾, 它自己的确就可以, 只要api都写的正确, 通过接二连三的resume->yield->resume>return就跑完了.

但lua结束了, 我的c server得继续啊, 而c server继续处理同一个连接的下一个请求的前提是前一个处理完了, 这就需要c server知道当前这个coroutine跑完了没, 这和lua的coroutine如何做到一路执行到底没啥关系啊

linux_c_py_php

{:3_190:} 额滴神, 我觉得我描述的挺清楚的啊, 总感觉你没理解我意思.

linux_c_py_php

starwing83 发表于 2013-02-24 18:59
回复 20# linux_c_py_php

就像我之前写的http server, 主框架是通过状态机注册write事件不停的去问插件是否结束了, server是不知道插件结束与否的, 这和插件哪时候结束没什么关系...

类似于lua这里, lua插件跑完了, 我的server不知道, 怎么办, 要么lua告诉我, 要么server去问

starwing83

回复 25# linux_c_py_php


    你不需要知道啊= =为嘛要知道呢= =

有请求，就resume，没请求，就挂着，就这么简单啊= =需要知道到底结束了没么= =Lua是垃圾回收啊= =如果一个请求完成了或者甚至是他没有新的请求了，那么就会在之后某个时间被回收了嘛 = =

linux_c_py_php

starwing83 发表于 2013-02-24 19:23
回复 25# linux_c_py_php

啊, 我真需要知道啊.

一个请求被解析了, 然后create coroutine了, 然后resume了, 之后各个api怎么resume与我无关了.

我哪时候继续解析下一个请求啊- -... 各玩各的么... 我真需要知道当前这个dead没了, dead了才能从main thread里pop掉这个coroutine让它回收掉, 然后我解析下一个请求... 再create coroutine, 再跑...

难道我从头就选错了实现方法了吗- -... 阿门啊

starwing83

回复 27# linux_c_py_php


    恩，你从头就错了。

你的服务器是一对多的，就是说，同时会处理很多个coroutine。

你需要在事件到达的时候，从一个映射表里面取得对应fd的那个coroutine，然后处理，然后pop掉。然后继续事件循环，再从有事件的那个fd取得另一个coroutine，然后处理，然后pop掉，不是一次处理完一个coroutine再下一个，这样就不是“协作式”了。

linux_c_py_php

starwing83 发表于 2013-02-24 19:33
回复 27# linux_c_py_php

不是... 我觉得你又误解我了, 我疯了...

这得往细节上说,  你仔细看一下我疑惑的重点:


① 一个request被一个coroutine处理完的标识是什么... 我答: coroutine dead.
② 作为一个server, 处理同一个连接上接连到来的请求, 必须是顺序处理的, 即一个连接同一个时刻只有一个coroutine。.
③ 在处理一个连接上的request的时候, server是不会继续读或者处理该连接上下一个请求的, 直到该连接上当前的request完成了.
④ request是lua异步执行的, server跑其他fd的事件, 与lua自己跑自己需要的事件没任何关系.
⑤ 当这个连接上的lua跑完（即这个连接的coroutine死了）了, server需要继续处理该连接下一个request, 但server在实现上来说是不知道该连接上的lua跑完的, 本来两者间就没有什么通知机制. 所以我说要server轮询检查每个连接上的coroutine死没死...不死就不能处理该连接上的下一个request, 该连接还得继续等其上的coroutine在后续事件循环中完成执行...

到底是什么情况- -... 是我执迷不悟还是交流有误解啊.

windoze

linux_c_py_php 发表于 2013-02-24 19:41
④ request是lua异步执行的, server跑其他fd的事件, 与lua自己跑自己需要的事件没任何关系.

这一点是错的，server等待事件，然后同步执行事件对应的session关联的lua脚本，只不过lua脚本跑一段就会返回，此时server检查lua是dead还是paused，如果是dead就销毁这个session。之后server继续这个循环。
如果你的server有多个thread（比如用LF pattern），那么这个过程在多个thread中同时执行，在此过程中，同一个session关联的lua脚本在不同阶段可能会被调度到不同的thread上，所以在其中不能使用TLS。

所以你标红的部分其实不是问题。