关于 PHP 最近的 RFC:Fibers

Pader2021年3月16日 发表于 网页与编程 coroutine php Fibers

PHP 在最近收到了一个可以实现协程的扩展 RFC:Fibers(https://wiki.php.net/rfc/fibers)。

Fibers 从本质上来讲是一个加强的,有栈的生成器,通过 Fibers 可以对整个调用栈代码无侵入式的暂停和恢复执行,再配合用户层面实现 EventLoop 和异步 IO,可以做到非常通俗易懂的,很常规的代码中实现协程,说人话就是最终做到不需要用 yield,不需要第三方扩展,即可实现纯 PHP 的协程,写法上和常规的代码没有区别。

但是这样的一个 RFC,却引起了诸多的争辩,尤其是国内知名的协程扩展 Swoole 的相关人员几乎全投了反对票。当然支持的人也是非常多。

相关讨论见:

https://www.zhihu.com/question/448805077

https://zhuanlan.zhihu.com/p/356942841

https://v2ex.com/t/748302

https://www.oschina.net/news/133232/php-fiber-proposal

开源中国文章截图

从韩天峰的角度说 PHP 协程要从长计议,fibers 可能只对 amphp 有利(amphp 是基于 yield/Generator 实现的纯 PHP 协程库,fibers rfc 正是该团队提出的),PHP 要出协程要从 EventLoop、内部组件的协程化、整个生态等方方面面全方位考虑。

对于 Fibers 我的看法是这样的:

  • 语言本身应该对特性做出最根本、精简的支持、尽量不做全套(这是库和框架该做的事)。

  • Fibers 本身已经接受很多意见,把 Fibers 精简为只是一个 Generator 的加强版,虽然目的是为了协程,但这个特性本身只是一个暂停/恢复的生成器,Swoole 本身也可以使用 Fibers,可见近些年的新星 Rust 对异步的支持上也是类似的做法。

  • 如果全方位考虑异步 IO 和协程有两点问题:

    1. 实现较难,讨论实现周期会特别长,等真的做出来恐怕已经是 N 年以后的事了,近几年各大语言关于协程特性的发展飞速猛进,所有其它的语言不是有协程就是有多线程,这两个重磅特性使他们在各种场景发挥着价值,而 PHP 还是在做 Web 而且还在流失。PHP 虽然从 7 开始,到 8.0 对执行性能有了很大的突破,但在其它语言的这些进步的特性上其实是微不足道,大量的 PHP 开发人员转移到 Java、Go 已经是不争的事实。如果再等几年,恐怕 PHP  会无力挽回这样的局面。

    2. 全方位考虑异步 IO 和协程恐怕会危及 PHP 现有生态,所有语言都害怕生态的这种变化。当 PHP 在语言层面做出巨大的功能性支持和变化时,会让原有的所有生态都老虑这种转变,学习的成本也会很大,会导致原有的优势也丧失殆尽,恐怕反而会加剧 PHP 市场的流失。比如 Java 一些古老的 jdbc 等各种基于多线程组件来看,Java 的协程化进展缓慢。Pecl、D、Python 2 -> 3 等各种语言在版本变化时所做的改变用了多少年才让大家有所适应,甚至是基本被淘汰出了市场。

  • 所以 Fibers 反而是最适合加入进来的,让 PHP 主线就支持 Fibers,让市场的选择去慢慢完善协程的生态。

其实最近这几年 PHP 界对协程的呼声一直很高,网上的各种讨论也早就有,比如 Swoole 扩展本身也对 PHP 的协程发展起到了很好的促进作用。比如在 fibers 之前就已经有一个叫作 fiber 的提案,还有其它的一些实现层出不绝,只不过进展缓慢,最后都被放弃了。好不容易 PHP 有这么一个稳妥的进步,我的意见就是百分之百支持。

截止目前为止,Fibers 赞同票 40 票,反对票 11 票,很大的可能 Fibers 会通过,从而进入 PHP 8.1。

时代的浪潮势不可挡,时代的发展也是各种因素导致,有些人和事促进了时代的发展,当时代发展起来之后这些人和事逐渐消退也是势不可挡,他们的贡献巨大,但更应该拥抱变化。

评论 共有 1 条评论