抛开使用领域来看的话就是：语法+标准库

还有一种悲剧，就是把为数不多的兴趣变成了工作。。。

内存 or 句柄泄漏，我这边用的中兴的光猫没出现过这个问题，路由器也木有

@terence4444 没体验过，此题超纲

个人比较佛系，就两个小时，随便坐坐看个片儿就过去了

@hhxsv5 Laravel 里面大量依赖了 di，而 di 的实现都是要依赖这组函数，所以想了解下你这块是咋处理的，因为看了下源码好像没有涉及 di 的改造

Coroutine:: call_user_func_array 可以将同步 io 挂起，继续去执行其他的协程，关键问题是，在框架中，没办法知道你开发的逻辑中是同步操作还是异步操作

运力是在提升，可是需求更大啊。。

@hhxsv5 这样的话同步调用就回阻塞整个进程

@hhxsv5 也就是说，作为框架，你根本不知道什么时候该用 call_user_func_array，什么时候该用 Coroutine::call_user_func_array，我之前也想这样干，后来不了了之

@hhxsv5 错了，只是调用内涉及 [同步 IO] 的操作需要 Coroutine::call_user_func_array，否则还是个大坑，不要问我为什么。。。

@hhxsv5 是的，所以看你怎么处理 di 的包

@server io 倒还好，大不了自己根据协议来封，关键 swoole 改了很多底层的东西，有点不可控。相比 swoole，个人觉得 reactphp 更稳定些。当然 go 更好~~

有遇到 di 的问题吗？之前用 swoole 的时候踩了 call_user_func_array 的坑，印象中 di 是肯定需要这个的

@Clarencep 替捉鸡。。。只要有一个会话开启了序列化，其他会话的事务操作都得等待这个会话结束。。。

@oswuhan 看清主题和回复，我自始至终也没“逼前端去做你认为是前端该做的事情”，别喷高潮了自我代入感太强

@oswuhan 我本来就不是前端。[滑稽]

@Clarencep 事务调整到序列化级别性能下降太厉害了