twosee

> > > > @twose 我是不懂，就纯粹问一下，望不吝科普。请问，mongdb协程化的难点在哪里呢？为什么不能像mysql数据库一样直接hook替换呢？ MongoDB官方更青睐于多线程模式，因此没有提供对多路复用的支持，这是一个原因。 PHP的MySQL客户端如PDO_mysql、mysqli等都是基于PHP自己开发的mysqlnd驱动运作的，而mysqlnd是基于php_stream实现的，php_stream提供了良好的socket操作抽象，因此可以很便捷地hook。

fibers已经集成到PHP-8.1并发布，我其实也参与了review和做了一些修改，但是你所说的一些事情可能并不会发生，正好借这个机会我也来解释、分析一下这些事情。 > 个人感觉应该是php8.1出来之后，比如 mysql、mongdo、redis之类的软件肯定会出适配8.1的协程驱动，这是一种趋势，也是把php蛋糕做大的唯一途径，也是官方希望看到的。 如果你指的官方是php-src的team，那么我也是其中的一员。 我本人以及Swoole社区一直在推进将这样的技术融合到php-src中，而fibers扩展的目的在我看来正是在阻止这样的事情发生，这也是我投反对票时所忧虑的事情。 ### 为什么你所期望的不会发生 fibers的RFC作者和我们是站在不同的立场上思考的，他提出RFC的目的很简单，仅仅是消灭`yield`关键字，而对于这之后的你文中所描述那些愿景，恐怕是RFC作者不愿意看到的。 在国外社区的大量讨论中，amphp的拥护者们极力反对了Swoole这样的给各种组件换驱动的方式，Swoole这样的技术已经在大量生产项目中得到了验证，他们给出的诸如破坏兼容性之类的反对理由无法令我信服（我们甚至做了一个叫做[php-bc](https://github.com/dixyes/phpbc)的项目来检查开启扩展协程hook后的测试表现和原生PHP有何[差异](https://github.com/dixyes/swow-bcreports)，而在跑了来自PHP内核的16000多个测试后数据显示，Swow扩展的兼容性高达99%，仅少数边缘情况和原生PHP行为不一致，甚至其中有一些是PHP的bug，反而在Swow的hook后得到了修复，我本人也是php-src team的一员，所以我很快把这些bug提交补丁修复了，这也是为什么我几乎不怎么看php源码也能经常给php-src提修复补丁的原因。） 我的拙见是，amphp社区花了大量精力研发了很多独立于现有PHP生态的异步组件，如果原有PHP同步阻塞生态的组件支持了协程化，那么他们所创建的这个异步王国将会直接破灭 —— 而我们知道fibers的RFC作者正是amphp的主要作者。 fibers特性确实能一定程度上提升amphp的吸引力，因为原有的yield关键字污染是个非常烦人的问题，但这就和FPM不管怎么优化怎么压榨性能都不可能跑得过Swoole这样的长生命周期的服务一样，它的上限早已被模型限制了。 amphp除了fibers都是PHP写的，包括协议解析，这里永远和C会相差数倍的性能。而PHP不像node是天生异步的语言，提供的异步支持只能说是非常有限，异步文件IO或者DNS这种想都不用想，根本支持不了，要支持只能改内核，如果amphp把这些全都往内核做了，那么最后我们会发现，这不就是Swoole吗？ 所以，如果你将主张合并fibers扩展的人看作PHP官方，那么你大概是不可能看到”官方“推出异步、协程的各种组件驱动了。Swoole、Swow一直是PHP协程生态的先驱者，在fibers合并后，作为PHP内核贡献者以及受到了PHP内核主要贡献者Nikita的邀请，我仍然积极参与php-src内核并推动fibers迭代，我也根据在Swoole中的开发经验提出了很多指导性的意见。但是fibers的RFC作者阻止了我继续做这些，他不仅拒绝了我写的补丁，还将我补丁中一些对于在我看来只对amphp有益而对接入Swoole没有什么帮助的部分自己提交了上去。因此我不得不认为，他们一定会竭力阻止Swoole这样的完整协程方案融入内核，而是会继续保持只有fibers这样的最小化的、仅能供amphp等库使用的东西在内核，我们甚至无法在Swoole中使用fibers特性，因为他们阻止了我们做出的有利于Swoole使用fibers的修改。 ### 为什么还没有提交RFC PHP社区的运作模式正是我们口中所谓的”国外的民主“，除了技术，它更多的还有政治上的博弈，国外社区缺少Swoole的舆论阵地，如果一个RFC在投票前没有得到社区的积极共识，那么进行RFC投票将是困难重重的，因为同样的RFC只能进行一次投票，我们只有一次机会，在中国流行的技术，在国外并没有那么快得到认可，而随着我们在国外社区的努力以及越来越多的国外项目尝到了Swoole甜头，局势也会产生变化，但这是渐进的，不是一蹴而就的。 ### 其它 在这件事情上其实没有对错，硬要说的话，我个人认为Swoole的方案更利于未来PHP的发展，那么amphp的方案对我来说就是错的。 我担忧的是，如果fibers成功促进了amphp社区的发展，那么PHP社区将会继续割裂成两个部分，同步阻塞和异步，你甚至可能会在未来看到await、async关键字 —— amphp会重建一切东西。 这时候有人可能会问，Swoole不也是吗？当然不是了，这样的割裂是自下而上的，当你想迁移到amphp服务器的时候，你不得不使用它所提供的异步mysql、异步redis、异步http组件，那么你的各种SDK，各种高度封装的库甚至整套框架，都无法使用了。而在Swoole中，我们看到了各种各样兼容性上的努力，我们致力于将各种原有的库，原有的SDK都能无痛地协程化，虽然不能0成本，但起码我们能实现**低成本的迁移**，当这个成本足够的低，那么随着流量增长，技术决策时切换其它编程语言的方案就会显得毫无竞争力，这也意味着PHP语言的竞争力被大大增强了。

> 不知道作者有没有向php官方提交合并到php-src的申请呢？个人觉得 http server 没必要用c去实现吧，swow不应只提供最基础的功能，然后其他的都使用php代码去实现么，这个应该才是最优解吧。就像是 java和golang，应用级别的功能全部是标准库实现。感觉swow有些地方又是走swoole的老路 这里你存在误解，Swow是使用PHP实现的HTTP Server，底层只提供最基础的协程Socket，非性能敏感的部分都是用PHP写的

@lanlin 首先，Swow的内核稳定性很久之前就已经生产可用级别了，如果是从数据量化的看，我们的单测覆盖率已经做到了非常高的水平，由于很多极端系统错误的case是几乎永远覆盖不到的，目前的覆盖率已经是很接近实际上能做到的最高水平了。 包括我们有一万多个[原生PHP兼容性测试](https://github.com/dixyes/swow-bcreports)，协程化PHP后，和原生PHP行为的兼容性为99%以上，仅个别极端情况行为有影响不大的出入。 并且我们的跨平台能力方面也做到了几乎极致，应该是目前最跨平台的PHP协程扩展，甚至连龙芯或者Windows Arm64这样的环境都支持了（并且是首个，甚至连PHP本身都没有支持，目前我们的团队成员 @dixyes 正在做这方面的工作，包括给PHP内核贡献Windows arm64的补丁）。你也可以在提交上看到我们在跑的自动化CI的数量已经非常多了，涵盖了各种环境和PHP版本。 我了解大家对于Swow发版如此关心是出于内核稳定性的考虑，但是其实这个和发不发版本没有关系，目前不发版本的主要原因是因为我们还没有办法确定API/ABI的稳定性，也就是我们可能还会重新设计部分API，如果是发了1.0的话，再想改API就比较棘手了。如果你能接受后续会有些许API变动的话，现在就可以使用Swow，否则可以再等等。据我了解已经有一些公司的生产项目在使用Swow了。如果你要使用像Hyperf这样明确支持Swow的框架的话，它对Swow的API都做了良好的封装，可以屏蔽掉API变化带来的影响。然后Hyperf3.0 或者 imi框架的未来版本 都会全面支持Swow，如果框架选型是用现成的这些框架的话可以再等一等。 其实很多TODO项在项目的Projects中有披露，只是由于时间原因，更新的不是很勤快。包括discussion中也有更新记录展示我们最近在做什么。内核扩展开发其实是一个曲高和寡，十年磨一剑的过程，并且Swow一直站在探索的最前沿，我们在设计一个东西的时候会考虑的很远，以免留下历史包袱，因此进展可能不会特别快。但是我们距离第一个大版本发布已经很近了，目前Swow的核心依赖libcat库已经完成了大部分开发，我们已经将大部分libuv的功能都协程化了，剩下是就是将C API封装成PHP API的一些工作了。 有很多已经实现的激动人心的特性我可能会在有空的时候通过写博文分享。 未来我们还计划协程化更多PHP已有生态中的同步阻塞库，其中非常流行的pgSQL和MongoDB是我们关注的方向，但是目前还处于研究阶段。 包括我们计划使用大量PHP来实现一些原本可能由内核实现的内容，未来Swow的可调试性将会极大提升。顺带一提，目前Swow在PHP-8.1下支持了Xdebug扩展。并且内置了类似GDB的SDB工具（由PHP编写），在调试上非常方便，且不影响性能。 我司目前是全栈使用PHP + Swoole的，预计明年的新项目会使用Swow作为内核驱动，现在已经有在开发阶段的项目了，所以对我来说，Swow v1.0发布的最佳时机应当是在我司亲自在生产中验证之后，因为很多不那么核心的小BUG需要在生产中才能暴露出来。 并且我们也在默默发展更多社区贡献者参与本项目，如果未来开发组的人力、资源能够满足，我们还有很多有利于PHP生态发展的宏大计划要开展。基于此，你也不必担心此项目会弃坑或不再维护。

目前比较通用的是结合task-worker的模式，即投递阻塞任务给task进程池，会多一层IPC的开销，性能会比协程差一点。 最好的方式自然是原生驱动的，pgSQL是官方驱动就有异步化API支持，这个后续Swow也会支持的，但是MongoDB是线程池的模式，官方都不支持异步，这个就比较困难了，但是我们正好也在计划支持中，还处于研究阶段。MSSQL优先级可能会低一点，可以通过task-worker解决。

创建客户端的时候opts参数传入['send_yield => true']即可解决

send_yield是grpc客户端源码里自己实现的，不是Swoole提供的。 贴一下你的报错？

不对啊，你Swoole啥版本的，Swoole很早以前就支持同时读写，一读一写了

这里底层实现有问题，因为recv的时候可能会触发帧更新，导致和写操作冲突了，我稍晚看看怎么解决一下

这个不完整, 只是禁止了一些常见的阻塞函数