宝塔

@chuanqirenwu 刚实现的 client ，还在测试

@chuanqirenwu 确实有 EventLoop. 最开始我是模仿的 JS, 因为我认为 JS WebSocket API 比 gorilla/nhooyr 这些提供的都要清晰得多. 初版只有 Sync IO, Read=>Event Handler=>Write 循环往复. 后面在此基础上加了 Async IO, AIO 模式在每个连接上有读写两个任务队列(并发度分别是 N 和 1), 就是我分享的这个实现, 它需要足够的轻量. 两种模式压测表现都比 gorilla 好得多, 原因大概是 Parser 本身的简单高效和无额外常驻协程吧, 如果有, 协程数量会增加一倍.

@MindMindMax 尽量使用 mutex 替代 chan. 很多时候保证线程安全就行了，不需要多线程通信. channel 我用得最多的地方是线程同步和超时控制.

@chuanqirenwu 同步模式没开额外协程，异步模式会开非常驻的协程，执行完任务就退出, 两种模式都没使用 channel.

待遇要求低, 身体好能加班

@rrfeng 另外几种"协程池"都用了 channel

@Nazz 这种方式不能保证 fifo ，并发小的话还是 heap 好点

@hsfzxjy
@securityCoding
其实最完美的结构是 stack. 我想到一种优化方式，先 push, 然后 swap(q[0], q[n-1]), 最后 pop

@voidmnwzp 你不妨说明白点具体是什么语言

@hsfzxjy 是一个优化点

@Mitt mutex 比 channel 轻量

@Glauben 加上 recover 结果也差不多

@ihciah 递归

和路由前缀树差不多，Reverse 一下就好了

@dw2693734d 自引用结构没法玩

并没有同时, 只是间隔很小

不能闲聊的话没人气的，我都不想在其他平台发技术帖了，无评论无 star ，完全是负反馈.

@lesismal 别这么卷了，下次我放-r 500 ，并列第一😅