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

fiber-rfc

PHP

协程

php-src

49 条回复 • 2021-03-23 15:36:49 +08:00

1

liuxu

2021-01-25 21:46:13 +08:00

早几年 7.0 就应该加上

2

Mitt

2021-01-25 21:49:56 +08:00

8

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

3

shoaly

2021-01-25 22:03:53 +08:00

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

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

4

alexkkaa

2021-01-25 22:08:46 +08:00 via Android

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

5

sagaxu

2021-01-25 23:30:43 +08:00 via Android

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

6

a632079

2021-01-25 23:35:17 +08:00

1

首先,传统 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 呢?

7

liuxu

2021-01-25 23:49:18 +08:00

1

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

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

8

mitu9527

2021-01-26 00:26:00 +08:00

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

9

back0893

2021-01-26 00:30:28 +08:00

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

10

Mitt

2021-01-26 00:30:44 +08:00

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

11

Mitt

2021-01-26 00:43:53 +08:00

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

12

sunznx

2021-01-26 01:28:52 +08:00

1

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

13

icy37785

2021-01-26 01:54:12 +08:00 via iPhone

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

14

rqrq

2021-01-26 06:48:32 +08:00

1

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

15

zjsxwc

2021-01-26 08:10:42 +08:00 via Android

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

16

RickyC

2021-01-26 09:16:06 +08:00

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

17

jeristiano

2021-01-26 09:33:34 +08:00

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

18

hpu423

2021-01-26 09:45:33 +08:00

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

19

Still4

2021-01-26 09:50:52 +08:00

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

20

limingxinleo

2021-01-26 10:40:16 +08:00

3

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

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

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

21

liuxu

2021-01-26 10:46:33 +08:00

@Mitt 站在 php 开发者角度，难在哪里？或者只是在你手里比较难

22

lscexpress

2021-01-26 10:51:18 +08:00

随便咯,官方出了我就试试,不出有这需求我就用 go

23

FantaMole

2021-01-26 11:45:18 +08:00

Who is the target audience for this feature?

Fibers are an advanced feature that most users will not use directly. This feature is primarily targeted at library and framework authors to provide an event loop and an asynchronous programming API

按这个 Q&A 的设想来看，即使引入了 fiber，对普通开发者的影响也不大，会有框架给出更简单易用的语法糖。我觉得主动尝试引入新特性对这个语言来说也是个好事吧，总比现在死而不僵要好