有人了解 PHP 官方目前正在讨论的 fiber-rfc 吗?

[Evilk]

如题 最近有了解到这个Fiber-RFC

如果合并进 php-src 底层直接支持异步或协程,类似 go 那样,会给 PHP 带来怎样的变化?

有感兴趣的 phper,来聊聊吧

[liuxu]

早几年 7.0 就应该加上

[Mitt]

异步 多线程 都不符合 PHP 的设计理念，一旦加入，大概率是改变编程习惯，这样的话 PHP 就会变成另一个语言了，所以要么是在原有的基础上适当改进加入，那这样大概率不痛不痒，要么就是完全改变 PHP 的运行方式，那这样不仅有破坏性改动，而且会大幅改变原有编程习惯，很多人会接受不了，PHP 的生命周期只到一次访问结束，这才是大问题，包括现有的 swoole 什么的，都极大破坏了原有编程习惯，或者这么说，能接受 swoole 的人一定可以换其他语言去做的更好，而接受不了其他语言的设计方式的人也不会接受 swoole 这种异步编程方式

[shoaly]

@Mitt 我也赞成, php 的优势就是写起来直白, 顺手.... 需要协程的时候 转 go 就行了, go 和 php 互动一下就行了...

不过从 php 官方的角度来说, 开发者可以不用, 但是不能没有, 不然老是在这几个[没有的功能点上] 被 go python 反复摩擦, 显得很弟弟

[alexkkaa]

这种异步要想发展起来就得伤筋动骨般的对内置库做大量改动。 参考 c#，标准库异步无处不在。反观 py， 标准库不跟进根本就发展不起来

[sagaxu]

PHP 变了，已经不是那个简单易用随手可撸的 PHP 了，那我为什么不直接用 Go 甚至 C#呢？

[a632079]

首先,传统 PHPer 仍然借助的是 CGI/FPM 或者基于 Apache 的 mod_php 来使用 PHP 业务的. 这种模式下, PHP 是收到请求开始初始化,执行代码,请求结束,直接销毁. opcache(包括 preload) 等优化方案只是对常用代码编译为 opcode(可以理解为 VM 中间代码,在运行时可以由 Zend 引擎直接转换为机器码(跳过分析过程), 这就是提速的原因之一.
PHP 8 引入了 JIT, 实际上是一个非常粗浅的 JIT(相比较 PyPy 和 V8), 而且受制于前述的生命周期,实际上的提升其实是非常有限的.
终于到正题了.题主提到的异步或协程特性其实并不太适合前表的生命周期,加入这类特性其实不会对性能有太大的提升,反而提高了学习门槛,提高了优化难度. 简而概之,对于传统的 PHP 开发,可能收益并没有那么大,做代码优化还不如堆机器.
这边提一句,如果真需要高性能 PHP 开发的话, 还是得回归 php cli 开发. 开发一个常驻内存的程序, 也就是目前 swoole 做的很成功的地方. 我相信如果 PHP 官方引入了异步,协程, 常驻类程序会收益匪浅.
#2 说的很对, Swoole 这种基于 Cli 的开发模式并不是 PHP 社区的热点, 和大家印象里的 PHP 迥然不同, 能接受 Swoole, 为什么接受不了 Go(特性少,简单), node, Java 呢?

[liuxu]

@Mitt 异步，多线程，都不符合 PHP 的设计理念，这个你是从哪得知的？还是你自己代表了 phper ？

据我看源码，php 的语言设计，本身是建立在 zend 内核上的一层实现（虽然有人吐槽太依赖 zend 了），在它之上才是 fpm 和 cli 之类的 sapi，你说的设计理念是 fpm 这一种 sapi 的实现而已？怎么就反客为主说这就是 php 的设计理念了？

[mitu9527]

@Mitt PHP 以前没有，并不代表现在不能有，很多人都期望加入异步和常驻内存等特性，PHP 就应该加入，除非做不到。时代在变化，PHP 不变就会落伍。

[back0893]

不咋样
那我为啥不换 go 或者 java
另外。workerman 也活的好好的。多进程不错

[Mitt]

@liuxu #6 不要过多关注底层设计，我们讨论的是语言层面，站在 PHP 开发者的角度去看这种改变你就知道异步、多线程为什么很难融入 PHP 了

[Mitt]

@mitu9527 #7 并不是一昧的去增加新功能就能跟上时代了，就跟 PY2 和 PY3 一样，PHP 一旦正式加入异步、协程、多线程，如果处理不好，势必会出现大版本分裂，可能会有 90%的 PHP 网站停留在旧版上，甚至转向其他更合适的语言，这对 PHP 是致命的，因为 PHP 相较于其他语言来说在这方面并不具备重大优势，所以这些特性很可能只会存在于一种可有可无或者半支持的情况下，那么第三方库可能就不会积极去选择支持它，常驻内存带来的另一个弊端就是内存泄露，这是传统 phper 根本不会考虑的事情，现在要考虑内存泄露、并发抢占、文件重载问题等等，会引入一大笔学习成本，PHP 只会在对现有 phper 没有重大负担的前提下加入新特性，比如静态变量类型

[sunznx]

@Mitt 你很强？什么时候轮得到你来说 phper 不会这些东西？

[icy37785]

@sunznx 会的不都转 go 去了么。剩下的就是不会的了的呗。

[rqrq]

我胡说八道一下：初期可以弄个并行函数，类似 swoole 的 go 方法，用来发邮件、写日志、网络通知这些旁路 io 操作。
能实现这个那就真牛逼了。

[zjsxwc]

挺好的，语言层面加入协程支持后，可以更简单地应对异步需求，不然只能手动 poll 来搞异步。

[RickyC]

@sagaxu C#? 听说目前在网站领域, php 占比还是很高的? C#太少了吧

[jeristiano]

我昨天看了这个提案，它提供最小化的核心支持 php 拥有全栈协程和绿色线程的能力，它不是 swoole 那样的一个异步通信引擎。
提案里说，异步非阻塞的能力会交个框架和其他的库，因此，这个提案并不会立刻为 php 带来协程工作流模式（ go,swoole ），仅仅是协程的具体实现(fibers)

[hpu423]

php，再不变,就真的是“世界上最好的语言了”

[Still4]

目前在用 zts，最难受的是上下文无法交互，开辟的子线程跟主线程内存隔离，虽然不会有并发读写的问题，但是也丢失了大量多线程的可用性

[limingxinleo]

上面说学习 Swoole 不如转 Go Java Node 的，真的有点站着说话不腰疼。

大多数写 PHP 的都是专科，搞 Java 的哪个不是本科起步，拿头去竞争么？

另外，PHP+Swoole 在开发上，甩 Java Go 好几条街。我本人 Go Java PHP Node 都写，但还是 PHP 配合 Swoole 写着最舒服，性能也不差，为啥非要去转语言，搞的自己议价能力直接拦腰折断呢