这是一个创建于 1385 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2021-03-17 09:29:07 +08:00
swoole 那帮人最近搞了个 swow，只包含 swoole 的核心部分，这次没有用 C++开发，完全按照能 merge 进 php-src 的代码规范开发，估计下半年也会写 rfc 发起投票要求并入 php-src 。
easyswoole & swoft: "你也有今天？"
easyswoole & swoft: "你也有今天？"
 |
1
weirdo 2021-03-16 09:06:46 +08:00
元芳你怎么看
|
 |
2
yxx1993 2021-03-16 14:42:27 +08:00
|
 |
3
zhao372716335 2021-03-17 08:48:44 +08:00
|
|
4
zhao372716335 2021-03-17 08:50:37 +08:00  1
韩的确是个很牛 xx 的程序员，但是最近这几年的的骚操作，越来越像个商人，越来越不像个开源系程序员。
|
|
5
zhao372716335 2021-03-17 09:01:38 +08:00
Fiber 本质上赋予了 PHP 在用户态临时暂停任意函数调用的特技。如果配合外部事件调度框架（可以完全用 PHP 实现），就可以实现 swoole 的大多数功能。而且，更关键的点在于，PHP 社区现有庞在的类库几乎只做很少的改动就能适配到 fiber 上进而获得并发执行的能力。这跟 swoole 需要内置各种协程版类库形成了鲜明的对比。最后，因为 fiber 会合并到 php 内核，由官方背书。一旦投票通过，会得到整个社区的支持。届时，swoole 就会被逐步边缘化。所以，swoole 相关的人就开始反对了。关于反对的内容，建议大家直接看原始讨论邮件，不要相信一家之言
|
 |
6
sorshion 2021-03-17 14:33:20 +08:00
最新解释在这儿： https://zhuanlan.zhihu.com/p/356942841
swoole 在几次事件中的表现，确实令我挺失望的。 本身提出的几点我觉得确实是有道理的 1. 从用户角度更希望一步到位的解决方案 2. fiber 不完整，后续 event loop 的实现，各家各异，确实一定程度上会造成内卷，哪怕经过厮杀，php 到时候早已热度不再 |
 |
7
sagaxu OP 1
@sorshion 6# 我觉得 rfc 解决的是语言特性，一步到位是框架和库的职责，我们不能因为用户主要用 orm 就否认 pdo 的价值吧，当 fiber 成为语言特性时，好处是显而易见的，
第一，衍生出各种基于 fiber 的框架。 第二，现有的库会考虑支持 fiber 。 实践一段时间之后，会有那么一两个比较好的 eventloop 和调度器方案成为事实标准，然后跟 fiber 一样进入 PHP 核心。分阶段一步一步来，等 php9 出来的时候，php 协程方案可能就成熟了。 fiber 其实有点类似 kotlin 的 coroutine，两类代码需要 bridge 粘合起来，不如 go 那般顺滑，但对一个有 20 多年包袱的成熟生态来说，也许是比一刀切更好的选择。 当然对 Swoole 不是什么好事，标准的主导权丧失了，英文文档和社区也拼不过，前景不容乐观。 |
|
9
sagaxu OP @sorshion 别担心，phper 转 Go 转 Java 是既成事实了，不会因为 fibers 或 swoole 有多大改变
|
|
10
zhao372716335 2021-03-27 22:58:26 +08:00
|
 |
11
mrpzx001 2023-01-03 10:35:55 +08:00
2 年了，fiber 玩出什么花了吗？
|
Select Language