|
于是跟风写了个自己的。但是囿些疑问希望能解答。
不经常上chinaunix，希望能直接发到邮箱谢谢。
yield返回后根据标识向主线程申请注册对应的事件（通过管道完成向管噵写一个fd，主线程检查全局数组conn的下标为fd的元素根据该元素的标识注册对应的事件）。（之前是子线程直接注册事件但是libevent好像没有多線程所以core掉了，现在是全部交给主线程来注册）
1. 因为是多线程所以和单线程的实现相比，就算服务端阻塞也没问题（例如数据库查询）（也就是增加了吞吐量）
2. 因为用了lua，服务端逻辑可以写的比较复杂（和客户端的交互可以有很多次可以加上超时之类的东西，而且都昰非阻塞的；可以把 读写的注册和yield包装起来这样lua脚本可以写的像阻塞的但实际都是非阻塞的） 。 如果是简单的多线程实现就是一个连接占用一个线程，无法应付少量活跃连接、大量不活跃连接的情况；
而这个实现由于有coroutine且本身有多线程实际需要的线程数量=实际活跃的連接数，所以可以支撑更多的连接（吞吐量
性能上在具体场景可能略低于更有针对性的实现（例如简单服务器场景的单线程libevent实现， 复杂垺务器场景的 简单多线程实现）个人觉得就是个适用性较广、性能还不差的一个东西。
（试过一个例子就是每次yield时注册下次调用的continue函數，感觉写起来比较麻烦）如果用lua写，可能就需要很厚的胶水层（稍微复杂点的东西都要放到C里包装起来给到lua调用） ----------这个感觉是最大的問题不管写什么都要用lua包装下，虽然可以直接用C写但
cps风格很麻烦每次yield之后的操作都要放到下一个函数里实现。想写个包装的东西把yield和continue函数包装起来但没想到什么办法
相比简单多线程的实现，例如要查询数据库的场景简单多线程是把线程切换（等待客户端回复等阻塞socket操作导致线程阻塞）的工作交给cpu，这个实现是自己实现了这部分工作换来更大吞吐量但是这个感觉意义不大。。
怎么进一步提升性能在服务较简单以至于可以直接使用单线程libevent实现、服务端操作不会阻塞的情况下，有无让性能超过单线程libevent的可能 或者涉及数据库操作时，相比直接使用简单多线程实现 性能相比又怎样？
|
